Our Thinking Wed 23rd March, 2016
Lessons learned from replatforming legacy applications
A few weeks ago I wrote a blog post about some of the work we’ve been doing for a government client, replatforming a suite of legacy apps from physical servers to the cloud.
With over 50 applications to replatform as quickly as possible to realise cost savings, we needed to work out the smartest way to scale up the approach we’d tested with a successful proof of concept. Now that we’re deeper into the process of doing this, I thought I’d share some pointers based on our experience so far:
1) Don’t have code owners
To speed up delivery, we’ve created reusable libraries and wrappers that can be used by all the applications we’re replatforming. It’s key that we don’t then introduce an artificial bottleneck, so we don’t have “code owners” – we allow all the teams on the programme to contribute to the codebase. The only proviso is that they stick to the club rules.
2) Scale your teams in line with the work
Before scaling up, we grouped all the different applications that best represent a given service. We then gave teams responsibility for a given service. This has allowed us to create seven parallel teams, who can work with minimal dependencies.
3) Decentralise decision making
We’ve seen immediate productivity gains from the decision to have each team take responsibility for its own service. Migration is happening faster, with fewer bottlenecks, while the heightened sense of ownership leads to better team morale – and higher quality code.
4) Decommission old hardware incrementally
There’s no need to wait until everything is moved to start making savings with decommissioning. Think smart about the order in which you decommission – and don’t be afraid to redeploy onto other kit you’re planning to decommission further down the line. By keeping the overall goal of cost savings in mind, we’ve been able to think inventively to realise gains as fast as possible.
5) Migration is only the start
The challenges of replatforming may take a lot of focus, but you should still keep life after migration at the forefront of your thinking. Knowing how you’ll support these applications, how you can make changes to them, and what good looks like should drive how you get there.
It’s likely that a lot of your business process and change management will alter as a result of migration work. To make the change easier, it’s vital to know early on what your new world will look like, so you can transition these processes in tandem with your applications.