Software modernisation is hard

Most people prefer to work on greenfield technology projects. After all, who doesn't like rolling their sleeves up and learning the latest on someone else's dime without having to wade through a mountain of technical debt created by cowboys who never wrote tests or performed code reviews.

Unfortunately, for every new system a company develops, there is often a core legacy system that must be overhauled. The longer a system has been in use, the more difficult it becomes to replace and failure to do so before time can mean a business will at some stage, face an existential crisis.

Background

Software modernisation can take many forms from least painful to most painful looking something like the following: wrap; rebuild; or rip-and-replace. Having worked on these types of projects, I have found there are key actions which can tilt the odds in your favour.

Consider these suggestions

Assemble your best team - At the risk of sounding elitist, modernisation projects are not the right place to onboard graduates or junior software engineers unless your project is well-advanced. Select a starting team of five of your most talented people who have previously worked together and get them to develop a proof-of-concept. Ideally, the architect on the project should have gained experience designing systems which required high scalability and served a user base of thousands at a minimum. Someone in the team also needs to have a deep understanding of designing secure systems.
Show the backlog some love - Modern agile software development does not mean winging it without requirements. You must allocate an experienced business analyst to the project who is capable of removing the creative tension that can exist between the team and product owner. It is OK if you don't know everything up-front but it is irresponsible and unfair to put decisions regarding key functionality in the hands of software engineers. The team needs to know, without any doubt, what the product vision is.
Start small - You have to start small, really small. No fanfare, ceremony, or pretence. Start by building a vertical slice of the system which will allow you to fire a tracer bullet through your architecture from the user interface through to the database. Load test the system to breaking point so that you can understand the headline performance characteristics of it and whether there are any glaring architectural flaws.
Involve customers and stakeholders - Committed stakeholders and informed customers are pre-requisites for project success. Vapourware and PowerPoint presentations repeated ad nauseum will not cut it. Show what you are building as nothing gets buy-in more than demonstrations of working software but remember to focus on your broader user base than one specific customer.
Challenge all assumptions - The people who developed your legacy systems may still be working for you. By all means, involve them in your modernisation efforts, but do not let them bring legacy thinking to the project as this will blind the team to the possibility of change. If you start hearing phrases like "our customers will never accept that" or "it has to work that way, we can never remove that feature" there is a chance they may eventually undermine your project. Watch out for this type of corrosive thinking.
Limit new technology choices - Modernisation projects do not justify building a technology "Frankenstack" for padding out a resume. Limit the adoption of new technologies to no more than two key aspects of the system. Continue to use your existing database platform to avoid the pain of data migrations. Also think very carefully about which front-end framework you adopt as the rate of change in web application libraries is frenetic and can feel like a constant struggle to keep up with.
Do not outsource all development - The core knowledge of existing systems resides within your company. If it is difficult for your team to comprehend existing systems, how can you expect a third party to have the remotest chance of doing so too? Only outsource the development of non-core systems if you face capacity problems and can cope with the overhead of managing the interface between internal and external teams.
Avoid lift-and-shift - If you listen to someone who says "just make the new system do what the old one does... but add all these new features", you will forever be playing catch-up. Like-for-like, or complete feature replication misses a golden opportunity to eliminate the wasteful processes embodied in your legacy system.
Celebrate meaningful progress - Small wins add up to big wins and help build confidence. Don't dwell on how much work remains. Without resting on your laurels, instead focus on how far you have come and what you and the team have achieved.

Concluding thoughts

Projects that under-deliver or fail aren't necessarily the result of poor technology choices, but more due to: how the team framed the problem; the skill of the people involved; the level of support that stakeholders provided; and the delivery approach that was used.

Irrespective of whether you are using the wrap; rebuild; or rip-and-replace approach, I have found that following the above suggestions, or not following them, can be a bellwether for success or failure on a software modernisation project.