Insights

There’s a tendency to think that moving a legacy system to the cloud means you’ve modernised it.

It doesn’t.

But if a legacy system is complex, tightly coupled and business-critical, lift and shift can sometimes be exactly the right first step.

Trying to migrate and rearchitect the system at the same time can turn one difficult problem into a huge unachievable ball-ache. You end up changing the infrastructure, the architecture and potentially the application itself, while still trying to keep the business running. That’s a lot of moving parts to introduce at once.

Lift and shift gives you something quite valuable: separation of the problems. Get the existing system into the cloud first. Stabilise it. Make it secure, observable and reliable in its new environment. Then start thinking about what should change.

And this is where cloud starts to become really useful. Once the system is there, you have options that may not have been practical before. Automation, managed services, modern deployment pipelines, better observability and the ability to progressively replace or rearchitect individual components.

You don’t have to bet the business on a big-bang rewrite. You can start pulling the architecture apart piece by piece, where there’s a clear business or technical reason to do so.

That’s an important distinction for me. I know most of you know this already but it never hurts to issue a regular reminder: Cloud migration and modernisation are related, but they aren’t the same thing.

The goal of a migration isn’t necessarily to arrive at the perfect cloud architecture on day one. Sometimes the real objective is to create the conditions in which you can finally build it.

Cloud doesn’t remove complexity by default. But it can give you the flexibility to do something about it.

To wrap up this series, a final observation. Architecture, product convergence, acquisitions, inertia, and integration seem like separate challenges on the surface. Looking back, I don’t think they are.

Every one of them came down to the same question: what was the organisation actually trying to optimise?

Technology never answered that question. Architecture didn’t answer it either. Engineering teams simply implemented the decisions that had already been made. Sometimes those decisions created value. Often, they quietly destroyed it.

Organisations rarely optimise for value. They optimise for whatever is easiest to measure: cost reduction, headcount, product consolidation, EBITDA. The spreadsheet becomes the driver — and before long, it becomes the strategy.

The irony is that the things customers and teams value don’t appear on the spreadsheet: trust, stability, product momentum, retained domain knowledge, long-term relationships. These assets are difficult to quantify, but remarkably easy to lose.

Cost can be measured. Value has to be recognised. Oscar Wilde famously described a cynic as someone who knows the cost of everything and the value of nothing. The same thing can happen in technology leadership. The numbers improve. The spreadsheet looks healthier. Yet somehow, the organisation creates less true value than it did before.

That’s the thread running through this series.

Technology doesn’t define success. It simply implements somebody else’s definition of it.

For most of my career, those definitions broadly aligned. Software businesses wanted to grow, customers wanted better products, and success meant innovation and commercial expansion. Different priorities, perhaps, but usually heading in the same direction.

More recently, I’ve experienced what happens when those definitions diverge. Many organisations — particularly in mission-driven sectors — exist for a very different reason. Those customers aren’t looking for rapid change or ambitious transformation. They value stability, predictability, and long-term partnership. Their focus is on delivering their mission, and achieving optimum value for money.

The software supplier, however, has its own objectives: growth, efficiency, product consolidation, increasing enterprise value. Neither perspective is wrong. But they don’t naturally lead to the same decisions.

That’s when engineering teams can find themselves in a position of compromise. They aren’t simply making technical choices anymore — they’re being asked to code one definition of success over another. A spreadsheet can tell you which option costs less. It can’t tell you which one creates more value.

That’s not a technology problem. It’s a leadership decision.

In my previous post I wrote about the hidden cost of delaying difficult decisions. The opposite can be just as destructive.

I’ve seen engineering teams reduced before critical knowledge has been transferred. I’ve seen products merged because they appeared similar on paper, only to discover they solved very different problems for different customers. I’ve seen platforms consolidated before anyone had really understood the architectural implications, and businesses standardise processes before understanding what had made the acquired company successful in the first place.

None of these decisions are unreasonable. Most make perfect sense in isolation. The problem is that they’re often made before the organisation fully understands what it’s trying to preserve.

The hidden cost of an acquisition is rarely the purchase price. It’s the value that’s unintentionally destroyed during integration.

That value isn’t always obvious. It exists in customer confidence, engineering capability, product momentum, architectural flexibility and organisational knowledge. These things rarely disappear because of one catastrophic mistake. More often they’re eroded by a series of perfectly rational decisions made with incomplete understanding.

One conclusion stands out. Doing nothing can be just as destructive as doing the wrong thing. The real challenge isn’t choosing between speed and caution. It’s understanding what creates value before either has the opportunity to destroy it.

When we evaluate the success of acquisitions, the conversation usually centres on the decisions that were made. I suggest the more interesting question is often which decisions weren’t.

It’s understandable. In high-stakes environments, nobody wants to make the wrong call, particularly when products, customers and people’s jobs are affected. But I’ve experienced organisations spend years trying to avoid difficult decisions altogether. Which product defines the future? What is the next generation architecture? What does the customer roadmap look like?

Until those decisions are made, the organisation doesn’t just stand still. It loses momentum. Engineering teams end up maintaining today’s complexity instead of building tomorrow’s platform. Product development stalls. Customers lose confidence. Your best people become disillusioned. Those consequences rarely become obvious until much later.

I’ve learned that the hidden cost of inertia is that organisations assume there is no consequence.

When organisations talk about product convergence following an acquisition, the conversation usually starts with technology. Which platform do we build on? Which codebase do we keep? How long will integration take? They’re reasonable questions but, in my experience, they’re not the hardest ones.

I’ve often found that products which appear remarkably similar on the surface have in fact evolved to solve subtly different problems for different customers. They’ve been shaped by different teams, different priorities and different use cases. Neither is necessarily right or wrong — they’re simply the product of different journeys. That’s usually where the interesting conversations begin.

Which product defines the future? Which features survive? Which customer roadmaps will continue to be supported? How much legacy function do you preserve before it becomes a millstone around your neck?

I’ve experienced my engineering teams being criticised because convergence wasn’t progressing quickly enough, when the technology itself was never the real constraint. The business simply hadn’t reached agreement on where it wanted to end up despite my promptings. Technology should only implement decisions. It shouldn’t make them. In fact when the former happens it is a disaster. The tail wagging the dog.

The more acquisitions I’ve been involved with, the more I’ve come to believe that successful product convergence is fundamentally about clarity. Once that exists, the technology is usually the easier part.

For most growing software businesses, architecture naturally remains an engineering concern. As long as the platform scales, customers are happy, and features keep shipping, it’s doing its job.

Then, the prospect of acquisition enters the equation. Suddenly questions that used to sit purely with the engineering team become board-level discussions. Questions about scalability, resilience and maintainability suddenly sit alongside discussions about valuation, risk and future growth.

At this point, architecture is no longer just about technology. It’s about risk. It’s about cost. It’s about the stability of your product. And, potentially, it’s about the value of your business.

I’ve seen organisations spend months, sometimes years, dealing with complexity that wasn’t fully understood before a deal completed. I’ve sat in meetings where a seemingly innocuous architectural decision made years earlier suddenly became central to discussions about integration, cost and timelines. Not because anybody wasn’t good at their job. Simply because architecture drifts while attention is focused on customers, growth and delivery.

Strong products, loyal customers and impressive growth can mask risks that only become apparent under closer scrutiny. A platform dependent on a handful of key individuals. Technical debt accumulated during years of rapid delivery. Products that looked complementary on paper present an architectural nightmare when you plan the integration.

None of these issues are necessarily deal breakers. But they can have a significant impact on the cost, complexity and timeline of what comes next. That’s why architecture eventually stops being just an engineering concern. It becomes a business concern.

With a little more time to reflect recently, I’ve been thinking about some of the more interesting challenges I’ve worked on over the years. Whether a software business is scaling organically, preparing for investment, or integrating an acquisition, many of the underlying technology challenges are surprisingly similar. At some point questions emerge around duplicated capability, platform strategy, technical debt, operating models and where future investment should be focused.

I have plenty of experience of acquisition and integration. Not the deal itself (that’s an SEP — someone else’s problem). I’m talking about the bit that comes afterwards for the technical teams involved. My experience is in bringing together products that have evolved independently, managing engineering teams with different cultures and ways of working, and dealing with architectures that solve similar problems in completely different ways.

I’ve worked through a number of these situations and I’ve noticed that many of the toughest decisions aren’t really technical. They’re product and business decisions with significant technical consequences.

Product convergence is a good example. On paper, it can look obvious. Two or more products with overlapping functionality. Rationalise them into one. Reduce cost. Simplify the portfolio. The reality is invariably messier. Customers use products in ways that nobody anticipated. Features that appear identical often aren’t. Technical shortcuts taken years ago can suddenly become critical dependencies. Convergence initiatives can move too quickly and create disruption that could have been avoided. More commonly, in my experience, organisations spend years maintaining multiple platforms because the difficult decisions are repeatedly postponed.

There are no perfect solutions. In the real world it’s usually a question of being pragmatic and making sensible trade-offs.

Over the coming weeks I’ll share a few observations from the engineering and architecture side of scaling software businesses, acquisitions and post-acquisition integration. Not because I’ve got all the answers, but because it’s an area that doesn’t seem to get discussed very often outside the organisations going through it — and sometimes inside those organisations too!