In a previous blog, I explained how to decide which is the right legacy transformation strategy for your application by evaluating different strategies sequentially. Now, it’s time to look at each strategy in a bit more detail, including when to choose them, the steps to take, the decisions to make and the issues you may encounter.
In this blog, I will briefly introduce some of the key points for each strategy to provide an overview of what’s involved. If you want to find out more about how to implement the steps mentioned or to avoid the issues raised, these can be found in our recently released ‘Modernising Legacy Applications in the Public Sector’ book.
Strategy one – Iterative modernisation
This strategy is about reviving an existing application so it’s maintainable, sustainable and able to evolve in future.
To choose this strategy, you need to be able to see a future path that involves continuing the investment in and evolution of the technology beyond the initial modernisation stage. In the case of off-the-shelf software, you may simply want to get your application into a state from where you can upgrade the product.
You will also need to consider whether you have the right capabilities at your disposal and the right access to the codebase to make iterative modernisation possible.
Steps to take, decisions to make
By proceeding with an iterative modernisation, your application should become easy to upgrade with security patches and provide a foundation from which you can plot a path for future investment in the technology.
Set your goals – Your first aim is to improve the application so that it is at least maintainable and supportable but you may need to change or add new functionality that enables you to meet an organisational or user need.
Start with an audit – You should start auditing the application to assess how you can get to this desired state, drawing on your earlier mapping to build your understanding of how the application is architected.
Implement a test harness – A test harness will help you to describe and verify how the application works before you start making changes, such as refactoring the code or upgrading versions and dependencies.
Replatform the application – If moving to the cloud is a key driver for modernising your application, you need to get it running on a new platform. While doing so, you should ensure that deployment and monitoring are automated.
Refactor the application – You can now safely upgrade dependencies and run your test suite to assert if it still works as expected. It is advisable to make changes that are as small as possible, so you can quickly detect what is causing your test suite to fail.
Add new value – At this point, your team should be able to add new functionality to the application if desired and needed, as well as begin implementing the plan for continued investment going forward.
Issues you may encounter
The issues you encounter when iteratively modernising will depend on the particular circumstances of the application you are attempting to modernise and the team responsible for doing the work.
Complexity of business logic – if you’re dealing with many lines of code that are hard for anyone to understand and follow, it’ll be hard to untangle and get to a stage where it is easy enough to understand and extract the core business logic from.
Bugs and workarounds – you may encounter bugs in the application that the people using it have developed workarounds for. When deciding to fix them, you need to consider that the bug’s behaviour is now expected behaviour.
Discontinued software dependendencies – You may find that certain dependencies are not available or that they run on old technology or on software that runs on old technology, which doesn’t match your modernisation strategy.
Strategy two – Iterative replacement
If iterative modernisation isn’t possible because the existing codebase or technology stack becomes a hurdle your team cannot overcome, you may be able to pivot towards an iterative replacement strategy instead.
You should consider this approach if the application you’re trying to modernise is a vital organisational cog that certain critical processes rely on. As your business processes are tied to it, you may be reluctant to buy or build new software to replace it, as this might mean having to change your processes too.
Delivering value to your organisation and its users by meeting user needs is of paramount importance and if this can be best achieved by delivering bespoke software or an off-the-shelf replacement, it’s likely worth the cost and can be justified.
Steps to take, decisions to make
When iteratively replacing an application, you should stick to the Government Digital Service (GDS) principles of understanding user needs and delivering in an agile way that iteratively progresses through discovery, alpha, beta and live phases.
Define components to be replaced – In order to iteratively replace the components of an application, you need to work out how to “decompose” the application. By trying to reduce the surface area of the application, you can slice up the functionality into components to be replaced.
Assess off-the-shelf replacements – Look at the product roadmaps and decide what the future holds for a product. It may take time and effort to introduce a replacement into your organisation, so you need to ensure the investment is worthwhile.
Reflect user needs in your architecture – Once you have defined components and assessed replacements, you need to come back to the architecture of your application and overlay your users’ needs, in order to decide what the future state of the application should look like.
Slice and sequence the problem – As you replace components, the changes should be sliced into small chunks that balance disruption and cost, while also considering the sequencing from a user perspective.
Retire legacy components – Once your replacements are live and you have moved users, you will gradually come to realise that legacy parts of the application are still live but with few or no users using them. You need to consider how you fully retire these components.
Issues you may encounter
By adopting an iterative approach, you are reducing risk by replacing functionality gradually and providing some level of functionality for users on an ongoing basis. However there are still issues you need to be aware of.
Switchovers may go wrong – One of the big risks of iterative replacement comes when you switch out old components for new ones. If it goes badly, you may need to revert while preserving the integrity of any data.
Overcoming complexity takes time – In attempting to mitigate these risks and take caution over data handling, your iterative replacement may take a lot longer than it would to replace everything all at once.
Getting lost in the detail – As you iterate through replacing workflows, you might feel like the process is becoming a bit of a mess, with systems running in parallel, different users at different stages of onboarding and service, IT and operations teams straddling all of it.
Strategy three – Big bang transformation
If an iterative and incremental approach to transformation isn’t possible, you are left with the option of transforming your application in one big-bang release. This inherently risky approach, which involves replacing the entire application and all its components in one go, should only be attempted as a last resort. You would usually only use the big bang approach for replacing an application with an off-the-shelf product. If you were developing a new application, you should develop and release it iteratively as there are few reasons to big bang custom applications.
One of the reasons you might resort to a big bang transformation is because you have concluded that both the iterative approaches would cost too much. Another is data complexity. As complexity increases, so does the likelihood of needing to resort to a big bang transformation.
Finally, you may also find that organisational constraints, such as deadlines brought about by licenses expiring or urgent policy changes, play a role in choosing this strategy.
Steps to take, decisions to make
Tread carefully if you choose to move forward with this type of transformation. You should rely on the important insights you have gathered in mapping your organisation and applications, as well as incorporating modern software techniques associated with agile development.
Find the right product for you – To find the sort of products that will not become legacy technology, you should refer back to the knowledge you have gathered about users and also consider the application mapping you did.
Test it with users – You should decide whether it’s possible to do a demo of the product and to test with users by sitting with them to evaluate the product and ensure their needs are being met.
Reduce risk with pre-production – Before you go live, you want to undertake further user research but with real data in a pre-production environment. This will be a valuable process to set up not just for your first release but all subsequent releases.
Form an iterative release plan – Think of your releases from a user perspective first and attempt to mitigate risks and disruptions to their daily routines in doing so. Also, consider adding users incrementally by moving a small subset first.
Consider creating a playbook – Although you should always aim for automated scripts for your code documentation, a playbook should also be considered. Anything that can’t be automated should be included, as well as instructions for using the automated scripts.
Plan your exit – Remember that you haven’t found yourself implementing a big bang release as a result of perfect circumstances surrounding your legacy transformation. Therefore you should start to think about how you can iterate beyond it and plan your escape.
Issues you may encounter
A big bang transformation, which replaces incremental change with an all-at-once approach, is inherently risky and brings a number of issues with it. By identifying what they are, it will be easier to mitigate the risk they cause.
Running parallel systems – To run the systems in parallel, you need to consider whether a) you have a team that is able to support them, b) you can keep the data in sync and c) your licensing agreements allow it.
Building tomorrow’s legacy today – Your choice of a big bang strategy will have been your last resort, so you need to recognise this compromise, avoid the mistakes of the past and plan for an exit.
All strategies require ongoing risk mitigation
Hopefully this blog has given you some idea of what each strategy involves and why you might choose them. As mentioned, you can find out more about all of them in ‘Modernising Legacy Applications in the Public Sector’ book.
Don’t forget that the iterative approaches allow you to reevaluate and pivot as you progress, which is why a big bang transformation should be reserved as an option of last resort. Every transformation strategy requires ongoing risk mitigation though and this is something you need to be constantly aware of.
