How to plan a smooth migration to Xperience by Kentico

A CMS migration is a redesign of content, code, data and operations. Treating it as a bulk copy creates a new platform carrying old decisions, missing exceptions and an editorial team forced into workarounds.

The plan below is specific to Xperience by Kentico where necessary and useful for other migrations in its general method.

Disclosure: Distinction is a Kentico partner. Product capabilities and migration guidance should be checked against current official Xperience by Kentico documentation and the requirements of the proposed implementation.

Define success and the migration boundary

Agree why the organisation is moving. Relevant outcomes might include supported technology, safer change, simpler publishing, consolidation, structured content or new client journeys.

Define what “migrated” includes:

• public content and media
• structured data and taxonomies
• forms and retained submissions
• users, roles and permissions
• redirects and external references
• integrations and scheduled processes
• custom code and administrative extensions
• analytics, consent and marketing functions
• archives and records that must remain accessible

Some material should be retained outside the new CMS, rewritten, archived or deleted under an authorised policy. Moving everything is not a neutral default.

Set outcome, quality, cost and operating measures. Avoid a launch date as the sole definition of success.

Audit the source estate

A URL export is only an inventory. Assess each content item for purpose, audience, owner, currency, evidence, performance, legal or records requirement and target treatment.

Use a controlled disposition such as migrate unchanged, migrate and restructure, rewrite, consolidate, archive or remove. Record approvals, especially for regulated, contractual or high-traffic content.

Inventory source-system features and customisations. Establish why each one exists, who uses it and whether the need remains. Include code, modules, web parts, jobs, integrations, reports and administrative changes.

Map URLs with traffic, backlinks and external use. Include documents, campaign links, QR codes, email templates and third-party directories. Redirect decisions need an owner and a destination that preserves intent; redirecting everything to the homepage is rarely useful.

Design the target before moving data

Create a target content model from the proposition, priority journeys and editorial needs. Define reusable types, fields, relationships, taxonomies, localisation, workflow and lifecycle.

Test the model with real source content, including difficult examples. A clean sample can hide rich-text formatting, embedded media, duplicated fields and content that has no suitable destination.

Editors should create, review, preview, schedule, localise and retire representative content during design. Guardrails should protect consistency without requiring development for routine work.

Agree the architecture for hosting, identity, search, forms, integrations, analytics, personalisation and deployment. Record decisions and consequences. Do not reproduce the legacy architecture simply because it is familiar.

Treat a KX13 move as replatforming

Kentico's current documentation describes an upgrade from Kentico Xperience 13 to Xperience by Kentico as creating a new project, migrating data and content, and manually transferring or adjusting code, customisations and unsupported content for architecture and API differences.

The migration toolkit documentation also states that tools cannot transfer every type of legacy data and that code and unsupported artefacts need manual work.

Therefore, catalogue:

• source Kentico version and hotfix state
• development model and codebase
• Page Builder and structured content
• administration customisations
• custom modules, web parts and scheduled tasks
• forms, marketing and commerce uses
• media and binary data
• authentication and integrations

For each feature, decide whether to migrate, redesign, replace or retire it. Confirm the compatible migration-tool and target versions in official documentation at delivery time; Xperience by Kentico follows continuing releases.

Build a repeatable migration pipeline

Automation can reduce manual effort, but every transformation needs rules, logs and exception handling. Keep source extraction read-only where practical and preserve an auditable mapping between source and target.

Run migration iteratively. Start with a representative slice, then larger rehearsal runs. Measure duration, failures, exceptions and reconciliation. Make the final run a repeat of a proven process, not a unique production event.

Freeze or manage source changes. Options include a short content freeze, incremental migration or controlled re-entry. Define who can publish during the transition and how updates are reconciled.

Validate counts and relationships, then sample quality. A matching item count cannot show that fields, links, permissions and meaning survived.

Maintain an exception queue with owner and disposition. Edge cases are expected; unowned exceptions become launch surprises.

Protect search and external continuity

Create one-to-one or meaningful many-to-one redirects for moved URLs. Preserve query behaviour where necessary and avoid chains or loops. Update canonical links, sitemaps, robots directives and internal links.

Test high-value and externally referenced URLs before launch. Monitor crawl, indexing and 404s afterwards. Search performance can move for many reasons, so avoid promising that a redirect plan will preserve rankings exactly.

Documents deserve special attention. A PDF may have backlinks, legal significance or an audience that bypasses the site navigation. Decide whether it remains, moves, becomes HTML or is retired.

Test the whole service

Testing should cover:

• functional journeys and integrations
• migrated content, media and links
• roles, permissions and authentication
• accessibility with manual and assistive-technology checks
• performance under representative conditions
• security and privacy controls
• analytics and consent
• resilience, backup, recovery and rollback
• editorial creation and governance
• operational support and incident handling

Define acceptance evidence and severity thresholds. Include real editors, service teams and representative users. A platform can meet technical specification while making ordinary work impractical.

Retest after material fixes and final migration. Keep production secrets and personal data out of lower environments unless their use is authorised and protected.

Plan launch as a reversible change

Prepare cutover steps, owners, timings, dependencies, communications and decision gates. Rehearse where risk warrants it.

Define rollback or forward-fix criteria, how data created after cutover will be handled and who has authority to act. Confirm DNS, certificates, caching, integrations, monitoring and support contacts.

Launch outside critical business periods where possible. Establish a focused support window whose duration depends on risk and evidence, then move into a named operating model.

Communicate with editors and stakeholders before, during and after cutover. Explain changed processes, support and known limitations. Training should begin with realistic tasks before launch and continue as needs emerge.

Govern time and cost through uncertainty

There is no reliable universal four-to-six-month migration. Content volume, customisation, integration, governance, data quality, team capacity and assurance determine the schedule.

Estimate in ranges after the audit. Identify unknowns and fund discovery or technical spikes. Preserve testing and migration rehearsal when pressure rises; reducing scope or phasing lower-priority content may be safer than compressing assurance.

Report forecast to complete, source-change risk, exception trends and readiness evidence. Problems found early are evidence that the process is working, provided they receive decisions.

Before commitment

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.

A smooth Xperience by Kentico migration is one in which source decisions are explicit, the target works for editors and users, automation is repeatable, exceptions are owned and launch is recoverable. The important planning happens before code, and continues until the new service can be operated safely.