Rehost, Replatform, or Refactor? Decoding the “6 Rs” of Legacy Modernisation for Your UK Business.
So, you’ve finally decided that your trusty old legacy system is starting to feel less like a trusty friend and more like a liability. It’s a moment every business leader faces. The big question isn’t if you should modernise, but how?
There isn’t a one-size-fits-all answer. After 15 years of guiding UK businesses through this exact process, I’ve seen that the right path depends entirely on your goals. Here at Full Metal Software, we’ve helped countless clients navigate these options.
This post will walk you through the six main strategies for modernisation, often called the “6 Rs”. We’ll look at the good, the bad, and the situations where each one makes sense. The goal is to give you a clearer picture so you can make an informed decision that fits your budget, timeline, and appetite for risk.
A Quick Look at the “6 Rs”
Before we get into the nitty-gritty, here are the six options we’re going to cover:
- Rehosting: Moving your old system to the cloud as-is. Think of it as a “lift and shift.” This terminology was widely popularised by AWS and others.
- Replatforming: Moving to the cloud but making a few small tweaks to take advantage of the new environment.
- Refactoring: Tidying up and restructuring the existing code to improve things like performance and maintainability, without changing what the software actually does.
- Rearchitecting: Making significant changes to the application’s structure, like moving from a single block of code (a monolith) to a more flexible microservices approach.
- Rebuilding: A complete rewrite of the application from the ground up, keeping the original purpose but with brand-new code.
- Replacing: Getting rid of the current application entirely and swapping it for something else, either off-the-shelf or a new bespoke build.
Choosing the right “R” helps you build a solid migration plan that balances resources, manages risks, and delivers a proper return on your investment. For instance, rehosting might offer a quick cost saving, whereas refactoring can set you up for long-term growth. It all comes down to the business case for your system.
Ready to modernise your legacy systems but unsure where to start? Download our Legacy Software checklist today!
Approach 1: Rehosting (“Lift and Shift”)
What is it?
Rehosting is about moving an application from your on-premise servers to a cloud environment with minimal changes. The system stays the same, it just runs on different infrastructure. It’s a straightforward approach, often used by businesses looking for a quick and simple solution, and it’s frequently the first step in a longer modernisation journey.
Pros, Cons, and Use Cases
- Pros: This is the fastest, cheapest, and lowest-risk option, at least initially.
- Cons: It doesn’t fix any of the application’s underlying problems or technical debt. You’re unlikely to be taking advantage of the cloud’s more advanced features. Careful selection of your cloud hosting is required to meet the GDPR requirements for UK companies.
- When to use it: This makes sense if the application is stable and performs well enough. Or if you have an urgent reason to get out of your current data centre. It’s also a good choice if budgets are tight or if it’s the first phase of a bigger plan.
Approach 2: Replatforming (“Lift and Reshape”)
What is it?
Replatforming involves moving your application to a new platform (usually the cloud) while making some minor modifications. The core architecture doesn’t change, but you can make small improvements to benefit from the new setup. In my experience with .NET, a common example is moving an older application to a managed service like Azure App Service, which handles a lot of the infrastructure management for you.
Pros, Cons, and Use Cases
- Pros: For a bit more effort and cost than rehosting, you start to see some real benefits from the new platform. You can often outsource platform management and gain some easy scalability.
- Cons: Just throwing more hardware at a system isn’t always the most efficient way to scale. This approach also doesn’t change the application’s core features, so legacy limitations will likely remain.
- When to use it: The use cases are similar to rehosting, but this becomes the better choice if you’re facing performance issues or want to offload some of the management of your tech stack.
Approach 3: Refactoring (“Restructure Existing Code”)
What is it?
Refactoring means reworking existing code to improve its structure without changing what it does. The main aim is to improve “non-functional” attributes – things that make the code easier to read, understand, and maintain. This can also be a very efficient way to improve performance without paying for more hardware.
Pros, Cons, and Use Cases
- Pros: This approach tackles technical debt, improves performance, and makes future development work much easier, which can dramatically reduce maintenance costs over time.
- Cons: Working on old code is never quick, so it can be time-consuming. Because it doesn’t add new features, it can sometimes be harder to justify the return on investment. It also requires a team that can get to grips with the existing code.
- When to use it: This is a great strategy when the core logic of your application is sound, but the code quality or performance has gone a bit pear-shaped.
Approach 4: Rearchitecting (“Materially Alter Architecture”)
What is it?
Rearchitecting involves making major changes to the application’s underlying structure. The goal is to enable it to perform better and take full advantage of a modern cloud environment.
Pros, Cons, and Use Cases
- Pros: This approach can lead to huge improvements in scalability, resilience, and flexibility. You’ll get much more out of cloud-native services.
- Cons: This is a high-effort, costly, and high-risk option. The more you change, the higher the chance of things breaking. You’ll need a robust testing plan and genuine expertise to even consider it.
- When to use it: This is for when your application’s core function is business critical, but its current architecture is holding back growth, scalability, or innovation.
Approach 5: Rebuilding (“Redesign from Scratch”)
What is it?
Rebuilding means creating a new application from the ground up. You don’t use the old code, but you do preserve the original scope and specifications (though you’ll likely improve them). You end up with fundamentally better software that is fit for purpose.
Pros, Cons, and Use Cases
- Pros: You get the chance to use modern technology and create a clean-slate application that perfectly meets your current needs. We prefer to do this incrementally to manage risk and deliver value sooner.
- Cons: This isn’t a quick fix and is probably the most expensive option on the list. If not managed well, it’s very easy for “scope creep” to set in.
- When to use it: This is the path when your current system is so outdated or problematic that trying to salvage it just isn’t worth it, or when you need modern features that simply can’t be bolted on.
Approach 6: Replacing (“Discard and Adopt New”)
What is it?
This is the most decisive strategy: removing the current application entirely and replacing it with a different product. This could be an off-the-shelf solution or a brand-new bespoke system.
Pros, Cons, and Use Cases
- Pros: You can investigate off-the-shelf software that might not have existed when your original system was built. If you find something that fits, it can be an easy and cost-effective choice. When you are looking at SaaS solutions, UK companies have to be careful about where their data is stored and processed, finding this out is often forgotten before you replace your current solution. If you go bespoke, you get the holy grail: a blank sheet of paper to design exactly what you need.
- Cons: An off-the-shelf product will probably not be a perfect fit. Building bespoke software means starting over with stakeholders and requirements gathering. Migrating data from the old system to the new can also be a major challenge.
- When to use it: Use this when the current system is beyond repair and no longer meets the needs of the business, or if an off-the-shelf product now offers far better functionality.
Approach 7: The 2 Bonus R’s
Retain: This is exactly what it sounds like. Just stick with what you already have. The obvious reason to take this approach is if it is working just fine, you don’t need new features and there are no underlying issues such as security or performance. If your budget doesn’t allow for one of the typical 6 Rs then it might be your only choice anyway.
Retire: Scrap and don’t replace. A common use case in situations where the functionality can be moved to other software in your organisation. Or if it’s broken but you can’t afford to fix it, often a sign that it is very low value to the business.
Feeling overwhelmed by the options? Let our experts guide you. We’ll help you navigate the “6 Rs” and create a tailored modernisation strategy.
Making the Choice: A Decision Framework
Let’s work through some questions to point you in the right direction.
Part 1: Quick Wins & Low Hangin Fruit
- Question 1: Is your main goal a fast move to the cloud with minimal fuss, just to get the infrastructure benefits?
If that sounds like you, Rehost is the fastest way to get there. Just remember it won’t fix any deeper issues.
- Question 2: Do you want to move to the cloud and make some light improvements for better performance, without rewriting everything?
If yes, then Replatform is likely your best bet, giving you some quick wins on the way to a modern setup.
Part 2: Deeper Modernisation – Balancing Effort and Reward
- Question 3: Is the application’s function still valuable, but the code is messy, slow, or hard to maintain?
If so, it’s time to Refactor. Tidying up the code will improve maintainability, performance, and reduce your technical debt.
- Question 4: Is the application still important, but its architecture is a roadblock to growth or adopting new tech (like microservices)?
A ‘yes’ here points towards Rearchitect. It’s a big job, but it will modernise your application’s foundations.
Part 3: Transformational Changes
- Question 5: Is the application’s function still needed, but the tech is so outdated that fixing it seems less sensible than starting over?
If this is the case, consider a Rebuild. It’s a high-effort strategy, but rewriting from scratch allows you to use modern tools and architectures.
- Question 6: Have your business processes changed so much that your custom system is no longer a good fit, or are there now off-the-shelf solutions that are a much better match?
If you answered ‘yes’, then Replace is the way to go.
Making Your Choice: A Visual Summary
Remember, these strategies aren’t always mutually exclusive. You might rehost an application now and then refactor parts of it later. Legacy Software Modernisation is a journey not a destination.
Conclusion and Next Steps
Modernising a legacy system can feel like a daunting task, but having a clear strategy makes all the difference. The “6 Rs” provide a framework to think through your options, each with its own pros and cons.
The key is to honestly assess your current system, your business goals, and your budget. Remember, these strategies aren’t always exclusive. You might rehost an application now as a quick fix, with a plan to refactor or rearchitect it down the line.
Ultimately, choosing a migration plan that aligns with your company’s needs is the best way to improve your operations and set your business up for future growth. If you’re not sure which path to take, don’t worry – that’s what a safe pair of hands is for.
Don’t let your legacy systems hold you back any longer. Contact us today to learn how we can help you unlock your business’s full potential through strategic software modernisation.
Your Next Steps:
- Inventory your current legacy applications.
- Use the quadrant map to perform an initial classification based on business value and technical condition.
- For high-value applications, begin a preliminary discussion with stakeholders about the goals: Are you seeking cost savings (Rehost) or new capabilities (Rebuild/Rearchitect)?”
Further Reading
We post extensively on this subject, so a great place to start is our Legacy Software Modernisation category.
Also don’t forget to get your copy of our Legacy Software checklist.
