My 3 part blog series on why full replatforms could fail – and what options you have instead.

Just rebuild it, it will be much easier.

I’m sure it’s a common phrase in digital transformation meetings. But for most organisations, that advice might not be realistic or may end up costing more in the long run.

In the tech arms race, there probably is pressure to tear down legacy platforms and go “composable” overnight.

CMS, DXP, DAM – all need to be agile, omnichannel, AI-enabled, and cloud-native by tomorrow, right?

But the reality is – large scale re-platforming can be risky, expensive, and might be in some cases unnecessary.

Instead, the smarter path is evolution – measured progress, driven by outcomes, not implied urgency. In this series, I’ll explore how to modernise your stack without the meltdown.

The Pressure to Rebuild Is Real

If you’re a developer, architect, or CTO you’ve probably heard one of these:

Let’s move everything to a headless CMS, it will solve our content problems.

We need a modern DXP. This one’s too rigid and we need the new features.

Our assets are a mess and fragmented. If we buy a new DAM it will solve all of our problems.

These are all valid concerns for anyone. But going from old to new in one leap is like changing a plane’s engines mid-flight – while flying full of passengers, not an easy job or one you really want to actually do.

Digital leaders will feel the pressure from the business to make changes including:

• Legacy fatigue from tightly coupled systems
• Perceived speed issues from marketing and leadership teams
• Technology envy when comparing stacks with competitors
• Vendor messaging that says anything but cloud-native is obsolete

Why “Rip and Replace” could be a trap for most

Rebuilding from scratch sounds clean. But in practice if not done correctly, it could look like this:

• 12-18 month timelines that drag due to data complexity
• Content freeze periods that block marketing teams
• Training gaps as users adapt to entirely new tools
• Lost knowledge buried in templates, workflows, and metadata
• Unrealised ROI as new platforms are underused or misaligned

And the biggest risk?

You replatform…

only to recreate the same monolith, just newer and shinier.

There is probably value in the Old Stack

Legacy systems are often battle-tested, integrated, and surprisingly, sometimes well-loved by business users.

They contain:

• Business logic tailored to real workflows
• Structured content that fuels SEO and paid channels
• Asset archives that are still relevant
• API integrations that power external systems

Replacing them straight away isn’t always necessary. Sometimes, it’s better to wrap, extend, and modernise around them.

Then replace them when you have decomposed

A Better Approach: Modernisation Through Evolution

You don’t have to choose between stagnation and full replatforming. There’s a another way:

Composable, connected, and outcome-driven evolution.

This means:

• Using modern services next to legacy systems
• Integrating via APIs, CDNs, and proxies
• Starting with areas of friction (e.g., campaign sites, asset delivery, personalisation tools)
• Delivering business value fast, then scaling change over time

What’s Next in This Series?

In Part 2, I’ll walk through some practical modernisation strategies for:

• CMS: how to run Sitecore XP and XM Cloud side by side
• DXP: composing a stack with CDP, Personalize, Send
• DAM: using Content Hub to modernize content supply chains
• Emerging tech: how AI and chatbots augment legacy workflows

In Part 3, I’ll explore real-world examples, roadmaps, and how to champion change inside your organisation.

Key Takeaway

You don’t need a wrecking ball to move forward. Modernisation is possible without the drama – evolve at your pace and appetite.

1. Start mapping where you are right now.
2. Deliver outcomes incrementally.
3. Build momentum by successfully delivering a composable part, then moving into the next.