You Are Here
As Julie Andrews once sang, let's start at the very beginning. It's still a very good place to start.
Chances are you're having some particular pain point or someone has noticed the costs and risks associated with remaining on legacy systems. But before you just start willy-nilly, you should build a definite roadmap to the future-state you're trying to achieve. It is possible to keep things going without a roadmap - and some have even succeeded - but the graveyards of industry are bulging with the remnants of those who failed to plan. We will avoid that fate by taking a different route.
Discover & Document
Begin with a complete audit of your systems. A thorough audit is a time-consuming process, but it pays off by giving you the best snapshot of what you're dealing with and as you proceed through your roadmap to modernization, you can use this initial document to map your progress.
In fact, while the metaphor of a roadmap is a useful one for describing the terrain of the present, it might be helpful to think of this is a battle-map. You're going to war against the past. When you've won, you will have a resilient IT ecosystem positioned to always be improving. That's the real destination. (Sure, you'll make friends along the way but the ROI on friends is unreliable compared to a rock solid cloud strategy and a good CICD pipeline.)
The first pass at a discovery & documentation project should give you a comprehensive list of the major systems your business relies on. You need to capture some key information to help rank your priorities.
- Name of System/Application
- Number of Users
- Maintenance Model
- License Type
- Physical Location
- Network Details
- Source Code?
- Admin Contacts
- Business Lead
- Connected Systems
- Date Purchased
- Last Update
- EOL info
For each system you also need to find out who the users are. How often do they use the system? What is the estimated value they derive from using it? In other words, you're trying to determine how business critical the application is to getting things done. Do other systems use the data from this system? Does this system rely on other (perhaps undocumented?) systems itself?
Once the discovery and documentation is complete, you now need to build a plan for modernization. It might be that you have one troublesome or at-risk system in particular driving this initiative - but until you've documented how all of your systems are interrelated and understand how the business depends on that particular system, it would be dangerous to attempt to replace that box.
How will you replace your legacy systems? Will you rip them out? Will you build in parallel? Will you migrate the legacy software to a modern cloud ecosystem? There are many approaches and yours will be unique to your business and situation.
Your strategy needs to take into account not just the system that is the anchor point for the project, but all the ways that your systems, business and processes interoperate. Chances are, your business relies on standardized processes that emerged over time organically as your company has grown. Many of those may not be well known, yet they are foundational. You will need to discover those processes as well as the systems and applications that they depend on.
Your plan should be a comprehensive chart of systems, start and estimated end-dates, impacted systems and processes, and it all needs to be well documented.
When you performed the Discovery and Documentation phase, you likely found one of two situations:
1 - the project was missing a ton of documentation, or had changed significantly from the time it was developed
2 - the project had lots of documentation (ideal) and it was still mostly up to speed
If you're lucky enough to be in the second category, just be sure to follow the pattern set forth by your predecessors. If you're in the first, then try to build out that documentation as you modernize. One really scary aspect of the truly modernized server ecosystem is that a cloud-based, containerized platform is harder to document if it gets forgotten. If your legacy systems are sitting in a physical server room, a forensics IT resource can discover everything about that box. If the box is a cloud instance somewhere out in the Internet, it is vital that you document its location in a common repository for the people who will come after you and your modernization team.
As you work through your project, you should be modernizing the platform and changing the culture to prevent being locked into future legacy modernization challenges. Work towards a future where continuous improvement means that the company is always improving and never dependant on expired licenses or outmoded hardware.
Change and Acceptance
The final part of your modernization project is one of the most frequently overlooked, but failing to manage it can mean your efforts will fail even if you get the technical aspects functioning. There is a layer of the IT where the people live and work. Those users need to be satisfied. You can't always make them happy, but if you fail to take them into consideration on your project you have missed the point.
All of the systems in a legacy modernization project are supposed to be in service of the business, and the business is comprised of people trying to perform the functions that make your work possible. People aren't like computers. People have a tendency to get used to things - even when conditions are horrible. People resist change. People don't like reorganizations. They reject changes to their daily routine. If you're speeding things up, they may be annoyed and perceive this as making more work for them, or as a risk to their employment.
You've got to communicate with the work-force and help them understand throughout the modernization project because they will want to know so many things.
- Estimated time-lines
- Performance benchmarks
- Challenges to success
- Interesting discoveries
- What the future-state goals are
Failure to keep them informed will likely doom your efforts even if you meet the roadmap goals. A good communication strategy may also help people remember important details about legacy systems you're replacing. Documenting the progress of your improvements while also remembering and celebrating the efforts of previous teams may also help give historical context to the work and remind people that while there are changes and hopefully things will get better and better, that you also remember the work of those bygone days. You're building the future but you can still honor the past.
Hopefully this isn't too scary. You might have come to find out how to replace one old box in the server room and we're telling you to change the world. You don't have to literally replace everything, but what we want you to consider is that true modernization should be a comprehensive, interconnected transformation of your systems in ways that promote stability, power, interoperability, and a clear path to future growth.