How to get migration cost estimates from experienced kentico solution partners

That spread isn't agencies padding their margins or lowballing to win the deal, though both of those things happen too. It's mostly a symptom of a bigger problem: most migration quotes get built on incomplete information, because most quoting processes skip the one step that actually determines cost, which is finding out what's really in the existing site before anyone prices the work.

Why the estimate matters more than people treat it

A CMS migration quote isn't really a price. It's a bet about how much of your existing site is straightforward to move and how much of it is going to fight back. Get that bet wrong in either direction and you end up in a bad spot: overpaying for a simple project, or worse, underpaying for a complicated one and finding out three weeks in that the "fixed price" wasn't fixed after all.

This is where the difference between a generalist dev shop and an experienced Kentico Solution Partner actually shows up. Not in the sales deck. In the quote itself, and in how much of the risk that quote has already priced in versus how much gets discovered later as a change order.

What actually drives the cost

Content volume matters, but it's rarely the biggest factor people assume it is. A site with 500 pages of clean, consistent content type usage can be cheaper to migrate than a site with 80 pages that were each hand-built with one-off page templates and inline styling. Cost tracks complexity more than it tracks size.

A few things tend to move the number more than anything else:

• Custom code and integrations. Every custom module, third-party API connection, and non-standard workflow needs to be assessed individually. A site with a clean CRM sync and a basic contact form migrates very differently from one wired into five different systems with custom middleware nobody's documented.
• Content model complexity. How many content types, how consistently they were used, and how much of the content was built with the intended structure versus jammed into a rich text field because it was faster at the time. The second kind is always more expensive to migrate cleanly.
• E-commerce, if it's in play. Product catalogs, order history, and payment integrations add a genuinely different layer of scope, testing, and risk compared to a content-only site.
• Design fidelity expectations. A pixel-for-pixel rebuild of the existing design costs meaningfully more than a redesign using the new platform's native components, because you're constraining the build against an old system's assumptions instead of building fresh.
• Platform distance. Kentico 13 to Xperience by Kentico is a bigger jump than a straightforward version upgrade, since there's no automated upgrade path between them. An older legacy version (EMS, Portal Engine, early Kentico builds) adds sequencing on top of that, because the upgrade tooling only moves one version at a time.
• SEO and redirect scope. A site with a clean, small URL structure is a quick audit. A site with years of URL sprawl, orphaned pages, and inconsistent redirect history takes real time to map safely, and skipping that step is exactly how migrations lose organic traffic.

Rough ranges, held loosely

Every one of these numbers depends entirely on the factors above, so treat this as a planning anchor, not a quote. A version upgrade on a straightforward site (think Kentico 11 to 12, minimal custom code) tends to land in the lower five figures and run a matter of weeks.

A full migration from Kentico 13 to Xperience by Kentico on a mid-size site with moderate customization is a different category of project, typically running into the tens of thousands and spanning several months once discovery, rebuild, content migration, and testing are all accounted for. Add e-commerce, heavy integrations, or a full redesign on top of that, and the number climbs from there.

If a quote comes in dramatically below that range without an audit behind it, that's not necessarily a bargain. It's usually a sign the estimate was built on assumptions rather than an actual look at your site.

What a credible estimate from an experienced partner should include

The estimate itself tells you a lot about how the project is going to go, before you've signed anything. A quote worth trusting usually has a few things in common.

It's built on an audit, not a guess. An experienced Kentico partner will want to look at your current site, your content model, and your integrations before putting a number on paper. If a quote arrives within a day of a single sales call with no technical review behind it, that number is a placeholder wearing a price tag.

It breaks the work into phases with separate estimates for each. Discovery and audit, architecture and content mapping, build, content migration, testing, and go-live support should each carry their own scope and cost, not get bundled into one lump sum that hides where the risk actually sits.

It names what's out of scope, explicitly. A good estimate tells you what it doesn't cover just as clearly as what it does. That's usually where change orders come from later, and a partner who's done this before knows exactly which gray areas tend to cause disputes.

It accounts for content migration as its own line item. This is the part generalist quotes most often underprice, because it looks simple from the outside and rarely is. Metadata, media libraries, taxonomy, and multi-language content all need their own validation pass, and an experienced partner prices that in rather than discovering it mid-project.

It includes a defined post-launch support window. Migrations don't finish the moment the new site goes live. A credible estimate accounts for a stabilization period afterward, because that's when the issues that only show up under real traffic tend to surface.

Questions worth asking before you request quotes

A few questions tend to separate a real estimate from a placeholder fast, and asking them upfront saves you from comparing numbers that were never measuring the same thing.

Ask whether the estimate is based on an audit of your actual site or a general assumption about a project "like yours." Ask what's explicitly excluded from the price. Ask how change requests get handled once the project starts, and get that in writing before comparing the bottom line against another quote. Ask for a reference from a similar migration, ideally one on a comparable Kentico version and content volume, not just a portfolio link. And ask directly how many Kentico migrations, specifically, the team has completed, not how many CMS projects in general.

That last one matters more than it sounds like it should. Kentico migrations have their own set of version-specific gotchas, and a team that's fluent in WordPress or a generic CMS stack isn't automatically fluent in the parts of Kentico that actually cause delays, macro resigning, licensing transfer, separated online marketing databases, page type remapping between architectures.

The honest version of "get multiple estimates"

The usual advice is to get three quotes and compare. That's fine as a starting point, but it only works if the quotes were built the same way. Comparing an audit-backed estimate from an experienced Kentico Solution Partner against a same-day ballpark from a generalist agency isn't really a comparison. It's two different documents that happen to have a dollar figure at the bottom of each.

The better version of that advice: request an audit before you request a quote, from a partner who's actually done Kentico migrations before, and treat the resulting estimate as the real baseline. Compare other quotes against that one, not the other way around.