Don’t feel trapped with your legacy IT system

Relationships with suppliers break down. It’s part of doing business. 

But what if that supplier built and maintains the legacy systems at the core of your business?

And what if those legacy systems seem too complex and unwieldy to just hand off to someone else?

That’s exactly the challenge a lot of our clients come to F12 with.

Maybe your incumbent supplier has expanded over the years, and now you’re a little fish in a big pond. Or the person who developed the system has gone, and you’re left with a junior team member (who doesn't quite get it). Or the system just isn’t performing the way it should—and your customers are starting to notice.

Whatever the reasons, relationship breakdowns with key suppliers can be stressful, and the thought of handing over those business-critical, legacy systems to a whole new supplier even moreso.

We specialise in taking over, supporting and developing legacy platforms. So much so that we’ve written the playbook for a successful legacy system takeover, so that when you do take the plunge with a new supplier, you know exactly where to start.

The Legacy System Takeover Playbook

The first thing you need to know is that you have options. No matter how complex your legacy system, no matter how embedded in your processes and operations, there is a developer out there just waiting to sink their teeth in and modernise it.

Before we begin

We need to get the lay of the land, digging into the code, and asking the difficult questions to get a deep understanding of the system, the business context, and the relationships that matter.

Start with discovery, not code

The first step in any legacy takeover? Discovery. 

What exactly are we dealing with here? What documentation do you have? In fact, why is the system in place at all, and more to the point, where does it fit into your business?

Thorough discovery isn’t just about the tech. Yes, we’ve got to identify critical workflows, key users, and pain points. But that’s a given.

Discovery is also about embedding into the business to get a deep understanding of the context and requirements we’re working with—so we can approach it with the real-world business use-case in mind, not just the software infrastructure.

Map the landscape

Once we understand the wider business context, we can drill into the details of the software.

This is the part where we might ask you to dust off any documentation you already have in place (even if it's a bit scrappy).

We’ll sketch the architecture: the components, integrations, and data flows. We’ll catalogue the dependencies such as frameworks, services, and third-party tools. We’ll note the infrastructure details, from hosting to backups, to the deployment process.

And then we can get stuck into the system takeover

Stabilise before you modernise

There’s not much point in modernising a legacy system if it’s not stable.

We prioritise uptime and reliability by ensuring backups, monitoring, and alerting are in place. If the system doesn’t already have version control and change management in place, we’ll add them too.

Upgrades and changes can wait until the takeover is done (or risk breakages and downtime).

Test incrementally

Those system breakages and downtime? The risk is vastly reduced with proper test coverage, built up gradually.

Start with smoke or regression tests around the most critical functions, then add tests when fixing bugs (to check before and after the fix).

Adding testing incrementally like this takes off the pressure for perfection right off the bat, and gives you easy reassurance that you can fix any issues that crop up.

Run in parallel

Running new components alongside old ones gives you a safety net for when things (inevitably) go wrong. 

Use mirrored traffic and shadow deployments to validate performance, then roll out changes to small groups of users first, keeping fallback to legacy, to reduce business risk and build trust in new changes.

There is a high cost associated with running systems in parallel, but the reduced risk (and the peace of mind that comes with having a backup when you make the big switch) is usually worth the added financial cost. 

Modernise by evolution, not revolution

When it comes time to modernise the system, we’re aiming for evolution, not revolution. 

“Big bang” rewrites might seem flashy, but they come at a high cost (and risk). One wrong move and the whole thing comes crashing down.

Take modernisation one step at a time, prioritising the changes that are most critical to the business and the users: typically performance, speed, and cost.

Apply strangler pattern (wrapping and replacing modules one by one), introduce APIs or service layers to isolate old internals, and containerise or automate deployment.

Evolution might be slower, but it also makes releases safer, so you (and your customers) have full confidence in the system.

Document and communicate throughout

By identifying exactly who we need to communicate with (and how we need to communicate with them) we can get key stakeholders on board and set expectations. In a legacy system takeover, things will inevitably go wrong. Having a plan, communicating with both customers and stakeholders, and documenting it all, can put minds at ease.

Working with (or around) the incumbent supplier

First, we need to address the elephant in the room: the incumbent supplier.

More often than not, the relationship may have broken down completely (hence the change), but even in the best of circumstances, a legacy system takeover can be unpredictable.

In the best-case scenario, there will be a positive, cooperative relationship. In which case, we can arrange a structured knowledge transfer with walkthroughs and gain access to existing documentation and logs.

If things aren’t going quite according to plan, though, and the incumbent supplier is uncooperative, we’ll move fast to secure credentials, repos, and servers first. Then we can rely on code analysis and system monitoring for the rest.

Make friends with business users

Building a working relationship with business users is just as important as those with key stakeholders and the incumbent supplier.

They know the system inside out, with all its undocumented quirks and workarounds, so involve them in prioritising fixes and improvements.

Early wins for business users build credibility in the system—fast.

Communicate progress in business terms

Communication with key stakeholders is a given, but translating those tech wins into business outcomes makes updates that much more tangible for non-technical stakeholders.

“Modernising system performance” might become “faster invoicing,” for example, and “upgrading security and testing” might become “fewer outages.” 

Communicating what progress means for them builds confidence and justifies the business case for continued investment.

Document as you go

Back in the discovery stage, we saw how essential thorough documentation is to a complex, business-critical system. 

Even partial documentation is better than none. Capture your learnings in real time, with diagrams, wikis, and runbooks.

Documentation helps onboard new team members to keep the system running as it should, for the long haul.

We go into projects with long-term thinking, but sometimes the worst does happen. Relationships break down and priorities shift. Thorough documentation gives you a smooth transition, future-proofing the system and reducing the risk associated with a new supplier.

Accept imperfection

Don’t aim to “fix everything.”

The focus with legacy systems is risk reduction, stability, and incremental improvement.

They rarely become elegant, and that’s fine.

If you’re not happy with your incumbent supplier (or you just want to explore your options for legacy system takeover and modernisation) please get in touch.