That scary old system with 'do not touch' on it? Your boss very much wants you to touch it. Now what do you do?

Migrating dusty mission-critical systems 101

Analysis Legacy systems have been sitting in server rooms for decades, gradually growing more complex in design, more expensive to operate, less understandable to administrators, and more indispensable to their owners.

If some hero tries to poke around inside them, their face turns white when they realize the machines are running all or part of some mission-critical function, such as manufacturing, payroll, or stock control, and any changes will be – how can we put this – non-trivial.

And that was OK until relatively recently, before these systems became exposed to new fangled stuff like web-based ordering and mobile apps. As such, application modernization has become a “thing,” and after decades of quietly performing their duties, these systems must either be updated or replaced.

But moving is complicated and very expensive. The people who built these systems will likely have left, while the documentation that may have helped in their absence likely doesn’t exist or – if it does – is woefully inadequate. It’s probable, too, that the only place you’ll be able to pick up replacement hardware is on eBay.

Nor is “migration” as a concept as straightforward an option as you might first think. There exists different models to choose from. Here's our gentle guide on what you need to consider and weigh up before heading off into the relative unknown...

People first

Before taking a pencil to the back of an envelope or breaking out the Excel and pivot tables, it’s important to understand who is driving the migration and what they want. That’s important, because getting a grasp on this sets the destination point of your migration, and the model of migration you will take.

Some migrations – in the case of “digitalization” – are business-driven. Francis Miers, director at IT services and software company Automation Consultants, said if this were the case, then businesses would likely be under pressure to deliver services to market ever more rapidly. “There is a constant pressure to keep up with the Joneses and to have all the latest features. This translates to the IT department as a whole set of projects,” he said.

In other cases, migrations are driven by the tech department – finding the technology answer to a bigger issue. Such tech-driven migrations can cause problems, too, according to IT services firm ECS consultant Des Trundle. “If it’s driven by the technology team, you’re on an uphill struggle from day one, because you’ll immediately be talking about what they see as the low-risk option, which is lift and shift,” he said. In most cases this is the most expensive route, but has the lowest return on investment.

In to this vacuum has stepped Amazon Web Services, which has published “six Rs” that, although focused on getting your data into its cloud, remains useful when considering migrations. What are those Rs? Retain, retire, rehost, replatform, refactor, and rearchitect. Lift and shift, one of the frequent approaches to migration, is covered by the AWS six pack.

The easiest option from the AWS six is to retain, which means keeping the application – and its existing box – where they are. According to Mustafa Musaji, solution architect for Linux shop and cloud spinner Red Hat, integration is your savior. “Much of what your greenfield applications need to function, like access to data and application services, is in the brownfield. Modern integration middleware can bridge the gap between new and old at the same time, providing the ability to scale,” he said.

“In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

Can you give us a lift?

But perhaps your old Apollo server is held together with elastic bands and making worrying whining noises. An alternative, rehosting, is what Trundle calls lift and shift. In this scenario, you create a like-for-like application migration to the target system.

In theory, it calls for minimal architectural changes. Companies will often adopt this as a cheap and cheerful option when migrating to cloud environments, but the dangers increase the older your environment gets, warned Trundle. You are not just dealing with application migration, he said. That legacy code can bring a whole OSI stack full of weirdness with it.

He gave data migration as an example. Some companies may try to move the application’s storage layer into a SAN infrastructure. “That’s absolutely fine until you go up the stack from your OS to your middleware and you suddenly find that the device drivers no longer work for the version of the OS you maintained,” he said.

Then, there’s the networking issue. “Your legacy machine was probably built in the days of token ring. It has isolated switches. You have 10,000 clients with hard-coded addresses to it and you want to move it to a new environment where you have IP mobility,” Trundle said. “Lift and shift explodes quickly.”

This is where the next two elements in Amazon’s six-point model come in: replatforming and refactoring. These involve making various degrees of structural changes to the application and its underlying technology to support the migration. The more changes you must make to shoehorn the old application into your new infrastructure, the more complex and expensive these options become.