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

No app left behind... well, probably some of them

Another option to reduce the technical challenges involved with rehosting is to use a well-worn concept in computing: emulation. Emulating legacy hardware can simplify the lift-and-shift process. It can get you up and running in a cloud environment by mimicking the underlying specifics of your older hardware and operating system configuration.

Emulation means that applications created for one architecture and operating system can run on a different platform without the need for modification, re-certification, or to migrate the source code. A side-produce of emulation, meanwhile, is you can swap legacy hardware that’s reached the end of its life for new virtualised environments – a move that can increase performance, lower costs, and help reduce risk.

The downside to such lift-and-shift arrangements is that your application won’t be optimized to integrate with a range of different services in a new technology environment. Anand Chandra, head of technology at IT services firm Synechron, warned that as organisations explore everything from mobile and social media integration to AI, legacy apps that don’t get a makeover could be left behind.

“Your user experience of a slow, sluggish back office system that generates reports that don’t arrive until the next day could become very dynamic. A system where you need to extract information monthly or quarterly could instead integrate with a real-time feed,” he said.

Out with the old

For those that want to recraft legacy systems for a modern business, the final, boil-the-ocean alternative is to simply replace them, rearchitecting the system altogether. This is especially useful when solving for cloud environments that offer benefits like instant resource provisioning, scalability and quickly reproducible infrastructure, according to IT services company Red Badger tech lead Viktor Charypay.

“Don’t do that as a big bang project though,” he warned, citing the recent debacle with Lloyds TSB’s banking migration as an example. “It is very likely to fail. You’ll miss something.”

There are often decades of institutional knowledge bundled into these applications. Picking them apart to understand what they’re doing and what their dependencies are can be a laborious process. Along the way, you may even find that half the applications running on that old VAX, PDP, or ICL system are no longer needed, giving you the chance to kill them off, said Trundle – or, as Amazon likes to say, “retire” them.

Synechron's Chandra recommended an analysis and architecture phase during which the migration team can pick over these applications’ individual functions and decide whether each needs to migrate across, and how they will change.

Companies might choose at this point to decompose the system’s functions into a set of services that the business can use. It’s an opportunity to recast them as reusable services that can be consumed by other applications, perhaps in a microservices model.

“Create a strategy document, complete this detailed analysis and architecture phase, and then create your minimum viable product,” Chandra said. “This proves that whatever existed in the heritage system, when you redraw it into the new, modern technology, is technically compatible and fit for business. Then once this baseline is ready, you can start building on top of it.”

Listen and learn

According to Red Badger's Charypay, his team learns what legacy systems are doing by “listening” to their message queue. By watching these transactions, they attempt to build a picture of the systems’ functionality. One approach involves building the minimum viable product in a modular way as this happens, adding functionality as more is learned about the message queue. The point is that, as some point, the new system mirrors its predecessor and its ready to take live.

If this sounds like an agile method of development, you're right – it is. Charypay advises using the same processes you’d see in agile development to pick off these functions piece by piece, migrating to alternatives in small, quick sprints that can be tested with users and other applications to ensure that they’re viable.

Migration comes in a range of flavors: from building an integration layer over an existing system to using emulation technology for a smoother rehosting process, or simply redeveloping from scratch. Each of them carries risks and rewards.

The models, though, are universal and they are agnostic. Before you go anywhere, you’ll need to figure out the destination point and who is driving things. Only then can you really deliver the migration that’s wanted. ®