Two-thirds of large technology programmes miss their targets on time, budget, or scope. I saw that BCG figure last year and honestly thought it felt low. Based on what I've seen across migrations at Distinction, the number that surprises me more is the 25% who say their migration delivered expected value within the first year. One in four. That's a pretty grim hit rate for something organisations spend serious money on.
None of that surprises you, does it? If you've been through a CMS migration before - even one that was ultimately deemed "successful" - you'll know the feeling. The quiet dread when someone discovers 4,000 pages nobody remembered existed. The integration that worked in staging and broke in production. The content editors who were trained on a Tuesday and left to fend for themselves by Thursday.
Migrations are always painful. We'll plan as well as we can and deal with problems as they come up.
I hear this a lot. And look - I get where it comes from. There's a fatalism that sets in after you've lived through a messy platform project. But the migrations we've delivered that went well weren't lucky. They were planned differently. Not planned more - planned at the right stages, on the right things.
What follows is the framework we use when planning a migration to Xperience by Kentico. Most of it applies regardless of which platform you're moving to. But the Kentico-specific considerations matter, particularly if you're migrating from an older version of the platform itself, and I'll cover those directly.
A quick disclosure before we go further: Distinction is a Kentico partner. We've delivered migrations onto the platform for years. I'm not going to pretend that doesn't colour the lens, but I'll try to keep this honest rather than promotional.
Before we get to the plan, it's worth being honest about the failure modes. Not the dramatic ones - total project collapse, vendor lawsuit, that sort of thing. Those are rare. I'm talking about the more common, more insidious failures: the migration that launches three months late, costs 40% more than expected, and delivers a platform the team is already working around by week two.
Five causes come up again and again.
The content audit that didn't happen. Or happened too late. Or happened at a surface level - someone exported a sitemap and called it an audit. Then halfway through the build, the team discovers 2,000 PDFs in a subfolder nobody knew about, a section of the site that's been maintained by a team in another office, and 600 URLs still generating organic traffic despite being five years old. Every one of those discoveries creates a scope decision that should have been made in week two, not week fourteen.
Architecture decisions made in a vacuum. I sat in a workshop a while back where the development team had already committed to a content model before anyone had spoken to the marketing team about how they actually published content. The architecture was technically elegant. It was also completely disconnected from the editorial workflow. They ended up rebuilding a chunk of it after launch - which is the most expensive possible time to change your mind about architecture. I'm not going to pretend I've never been in a room where that kind of thing happened on my watch. It's embarrassing when it does.
Data migration treated as a task, not a workstream. URLs, redirects, structured content, media assets, metadata, user accounts, form submissions. Each one has its own complexity. Each one has edge cases. I've seen firms lose a significant chunk of organic traffic because the redirect strategy was an afterthought. Real money, gone, for no reason other than it felt like a detail.
Inadequate testing. Not just "does the page load" testing - that's the easy bit. Does the content editor know how to create a new service page without calling a developer? Does the personalisation actually fire for the segments you've defined? What happens when someone hits the site on a three-year-old Android phone over a patchy 4G connection? The testing that gets cut when timelines compress is always the testing that matters most for adoption.
Stakeholder management that's really just stakeholder notification. Sending a monthly status email to the senior leadership team is not stakeholder management. Training the content editors in a two-hour session the week before launch is not change management. The people who use the platform every day need to be involved throughout, not surprised at the end.
Here's the framework. Five stages: Audit, Architecture, Migration, Testing, Launch. They're sequential, but they overlap - the boundaries aren't rigid. What matters is that each stage has a defined purpose and defined outputs before you move to the next.
This is the stage that everyone agrees is important and almost everyone underinvests in. I've started saying in kickoff meetings: "The audit is the project. Everything after the audit is just execution."
Slight exaggeration. But only slight.
A proper audit covers four things. First, content inventory: not just what pages exist, but what content is on them, who owns it, when it was last updated, whether it's still accurate, and whether it should migrate at all. We worked with a professional services firm that had 1,800 pages on their legacy CMS. After the audit, 640 were worth migrating. The rest were duplicates, outdated, or pages that existed because someone once asked for them and nobody ever removed them. That's not unusual - it's actually fairly typical. What was unusual was how surprised the client was. They'd been maintaining a platform full of content nobody needed, paying for it every month, and had no idea.
Second, integration mapping: what connects to the CMS today, how, and whether those connections need to be replicated, replaced, or retired. CRM integrations, marketing automation, analytics, third-party data feeds, API endpoints. All of it.
Third, URL and redirect inventory: every URL that receives traffic, has backlinks, or appears in external systems needs a migration plan. Painstaking work. Also the difference between preserving your search visibility and torching it.
Fourth, customisation inventory: what's been customised in the current platform, why, and whether that customisation addresses a real need or a historical workaround. This one matters particularly for firms migrating from older Kentico versions, which I'll come back to.
Architecture is where you decide what the new platform will actually do. Content types, page templates, editorial workflows, personalisation rules, integration points, hosting configuration. The decisions made here determine the ceiling of what's possible on the new platform and the floor of what it costs to maintain.
Two principles I'd push on hard.
First, design for the editors, not the developers. The development team will be gone in six months. The content editors will be living with your architecture decisions for years. If a marketing manager can't create a new campaign landing page without filing a support ticket, your architecture has failed - no matter how clean the code is.
Second, don't replicate the old platform's architecture on the new one. This is the most common trap I see, and it drives me slightly mad. The team migrates every content type, every template, every workflow from the legacy CMS because it feels safer than making decisions about what to change. But you've just spent significant money to end up with a new platform that works exactly like the old one - including all the bits that didn't work well. A migration is a chance to fix things. Take it.
The actual movement of content and data from old platform to new. This is where our Henry accelerator earns its keep - it uses AI to handle the heavy lifting of content and data migration, cutting the time and risk that typically makes this stage the most stressful part of the project. But regardless of tooling, three things matter.
Automate what you can, but plan for exceptions. No migration tool handles 100% of content cleanly. There will be edge cases - rich text with embedded formatting that doesn't translate, media assets with broken references, content that was structured one way in the old CMS and needs restructuring for the new content model. Plan for these. Budget time for them. They're not failures of the migration tool; they're the reality of moving between different systems.
Run the migration more than once. A dry run - ideally two or three - is essential. Each run reveals problems you didn't anticipate. By the final run, you should have a predictable, repeatable process with known exceptions and defined handling for each one.
Don't migrate everything. This connects back to the audit. If content doesn't deserve a place on the new platform, don't bring it along.
Testing isn't one thing. It's at least four things, each serving a different purpose.
Functional testing confirms the platform works as specified. Pages render, forms submit, integrations fire. Most teams do this reasonably well because it's the most obviously necessary.
Performance testing confirms the platform works under load. What happens when 500 people hit the site simultaneously? What about 5,000? If you're a professional services firm with seasonal traffic spikes - around results announcements or regulatory deadlines - test against realistic peak loads, not average ones.
Accessibility testing confirms the platform meets WCAG standards and, more practically, works for people using assistive technologies. Increasingly a legal requirement, not just a best practice.
Editorial testing - the one that gets cut first and matters most for adoption - confirms that the content team can actually do their job on the new platform. Can they publish a news article without help? Update a service page? Create a new landing page using the components available? If they can't, your go-live date is premature, regardless of what the development team says about technical readiness.
Go-live is not the end of the project. I'll say that again: go-live is not the end of the project.
A good launch plan includes three things most teams forget. First, a rollback procedure: what happens if something critical fails in the first 48 hours? Can you revert to the old platform? How quickly? What's the decision criteria for triggering a rollback? Having this plan doesn't mean you'll need it. It means you'll make better decisions under pressure if you do.
Second, a communication plan for internal teams: not just "the new site is live" but a structured series of updates covering what's changed, what to expect, who to contact with problems, and what's coming in the next phase. Content editors who feel abandoned after launch are the ones who build workarounds that quietly undermine the platform's value.
Third, a post-launch monitoring period: a defined window - usually two to four weeks - where the implementation team is actively monitoring performance, fixing issues, and supporting the editorial team. The project isn't handed over until this period is complete and a defined set of acceptance criteria have been met.
If you're migrating to Xperience by Kentico specifically, a few things are worth flagging.
The jump from Kentico 12 or 13 to Xperience by Kentico is significant. This isn't a version upgrade - it's an architectural evolution. The content modelling approach is different. The page builder works differently. The way you handle personalisation has changed. Treating this as a simple upgrade rather than a platform migration is one of the most reliable ways to end up with a project that runs over. I've seen it happen. It's not pretty.
Existing customisations may not have direct equivalents. If your current Kentico instance has significant custom modules, web parts, or integrations, each one needs an architectural decision: rebuild on the new platform, replace with a native feature or third-party tool, or retire. This analysis should happen during the audit stage, not during development.
URL strategy for non-Kentico migrations. If you're moving from a completely different CMS - WordPress, Drupal, Sitecore, whatever - the URL structures will almost certainly differ. Your redirect strategy needs to account for every indexed URL, every URL with external backlinks, and every URL that appears in print materials, email signatures, or third-party directories. Miss this and you'll spend months recovering organic traffic you didn't need to lose.
Test the marketing features properly. Xperience by Kentico's personalisation and digital marketing capabilities are frequently cited as reasons for choosing the platform. Make sure you test them as part of real editorial workflows with real content and realistic audience segments - not in isolation against a demo dataset. A personalisation engine that works in a demo but hasn't been configured for your actual use cases isn't delivering value. It's just ticking a box.
A mid-market CMS migration to Kentico Xperience typically takes four to six months from kickoff to go-live. That assumes moderate content complexity - say, 500 to 1,500 pages of active content - a defined integration footprint, and a team that can commit appropriate time to the project.
Significant content volumes, complex legacy integrations, heavy customisation debt, or limited internal resource availability? Plan for longer. Six to nine months isn't uncommon and isn't a failure. It's honest scoping.
The temptation to compress the timeline by cutting the audit and testing phases is one of the most reliable predictors of a painful launch. The board wants the new site live by Q3. The audit gets compressed from four weeks to two. Testing gets compressed from three weeks to one. Then the team spends Q4 fixing things that should have been caught before go-live. I've watched this happen more times than I'd like to admit - and once or twice, I've been the one who didn't push back hard enough on the deadline. That's a regret. The organisations reporting migration fatigue and delays of six months or more? A lot of them got there not because the project was inherently complex, but because the planning was compressed to meet an arbitrary date that someone put in a board presentation.
I've left this until last because it's the section most likely to be dismissed as soft stuff. It isn't.
Your content editors have spent years building muscle memory around the current platform. They know its quirks, its shortcuts, its limitations. They've developed workarounds for its worst features and they're genuinely productive with it, even if the platform itself is objectively poor. Moving them to a new system is a change management exercise, not just a training exercise. They need time with the platform before go-live. They need a support channel after go-live. And they need someone to actually listen when they say "this doesn't work the way I expected" - not just be told they need to learn the new way.
Marketing leadership who've been promised a launch date need honest, regular updates. Not monthly status decks that bury bad news in green RAG ratings. Actual conversations about progress, risks, and trade-offs. If the timeline is slipping, they need to know why and what the options are - not a silence followed by a delay announcement that destroys confidence in the project.
And senior leaders who approved the budget? They need to understand that a well-managed migration is one where problems surface early and get resolved in planning. If your technology team is bringing you problems during the audit phase, that's a sign the project is well-run. It's not a sign it's in trouble.
Before any migration conversation, it's worth understanding how ready your current environment actually is. We've put together a CMS migration readiness assessment that looks at the factors most likely to affect your project's timeline and complexity - content volume, integration footprint, customisation debt, internal resource availability, and stakeholder alignment. It takes about fifteen minutes, gives you a traffic-light view of your readiness, and produces something concrete to share with your managing partner or CFO before the investment conversation. Free, and there's no sales call attached unless you want one.
Migrations don't have to be painful. But they do have to be planned. And the planning that matters most happens before anyone writes a line of code.