Which Kentico content types migrate directly to Umbraco and which need workarounds?
Pages, custom page types, media files, users, roles, languages, and URL redirects all have direct or close mappings in Umbraco. Seven entities require workarounds or manual reconstruction: form submissions need Umbraco Forms' database tables or a custom SQL table; categories have no native equivalent and must be rebuilt as Document Types or custom Data Types; contacts map loosely to Members with likely field loss; workflows require a package like Plumber or external tooling; page attachments migrate as Media items but links must be reestablished; custom tables require a decision between Document Types, custom DB tables, or an external store; and workflow history is generally archived rather than migrated live. ClonePartner identifies which path applies to each entity during the scoping call so nothing lands silently in the wrong place.
Do Kentico categories migrate to Umbraco?
Kentico's category and taxonomy system has no native equivalent in Umbraco, so categories are marked as unavailable in a direct migration. The standard approach is to recreate the taxonomy structure as Umbraco Document Types or custom Data Types before the migration runs, then map content records to those new structures during import. If this rebuild step is skipped, category relationships will be lost and content will arrive without its taxonomy assignments — there is no way to recover them automatically after the fact.
What happens to Kentico form submissions when migrating to Umbraco?
Kentico form submission data cannot be imported via Umbraco's standard APIs; it requires direct access to the Umbraco Forms database tables (UFRecords, UFRecordFields) or a custom SQL table if Umbraco Forms is not licensed. Before any submission records can land correctly, the corresponding Umbraco Forms form definitions — including their field GUIDs — must already exist in the target environment, because submission records reference those GUIDs as foreign keys. If forms are being rebuilt rather than migrated in parallel, historical submissions should be held in a staging export until the form schemas are confirmed, or migrated to a separate archival store. Kentico's own API does not support form submission export, so extraction requires direct database access to the Kentico instance.
What version of Kentico and Umbraco do I need for this migration to work?
On the Kentico side, the Management API surface varies significantly by version: Xperience by Kentico (the current SaaS-first product) has the most complete REST API, while Kentico Xperience 13 and earlier rely heavily on the .NET CMS.DataEngine for bulk operations rather than REST endpoints. Portal Engine projects must have already moved to MVC before a migration is feasible, and custom module class and page type definitions must be migrated before their associated content records. On the Umbraco side, the Management API (v1) is only available from Umbraco 14 onwards; older versions require legacy endpoints, and Umbraco Cloud deployments add restrictions on direct database and filesystem access that affect how media files and form data can be written. ClonePartner confirms version compatibility and access requirements during scoping before any migration work begins.
What do we need to rebuild or reconfigure manually in Umbraco after the data lands?
Several things require manual attention after migration regardless of how cleanly the data transfers: user and member passwords cannot be migrated due to hashing on both platforms, so all users must reset passwords after cutover; URL redirect targets depend on whether the Umbraco built-in Redirect Manager, the URL Tracker package, or IIS rewrite rules are used, and the chosen approach must be set up before redirects are bulk-inserted; multisite or multi-root configurations need domain and hostname reconfiguration in Umbraco's backoffice; and property editor aliases in Umbraco Document Types must match the migrated field names exactly or data will be silently dropped on render. Workflows are a rebuild task in Plumber or equivalent — ClonePartner can migrate workflow state metadata as archived content nodes, but the live approval logic must be reconfigured by your development team.
Is there a risk of silent data loss when Kentico custom tables are migrated to Umbraco?
Yes, if no target structure is defined before migration runs. Kentico Custom Tables are structured relational data with arbitrary schemas, and Umbraco has no native equivalent — so the destination (Document Types, custom database tables via the Umbraco Migrations API, or an external store) must be agreed and created in advance. If a Custom Table row references a category, a related page, or a custom module object that has not yet been migrated, that relationship will be broken on import and may not be recoverable without re-running the affected segment. ClonePartner maps each Custom Table's schema during scoping, proposes a target structure, and validates record counts and referential integrity after load to surface any breaks before cutover.
How long does the Kentico to Umbraco migration take?
Most migrations complete within 1–5 business days, depending on data volume and complexity. We provide a detailed timeline after the initial assessment and can often complete small migrations in under 24 hours.
Will my team lose access to Kentico during the migration?
No. Your source system remains fully operational throughout the entire migration. We run the migration in the background with zero downtime to your current operations.
Will there be downtime when migrating from Kentico to Umbraco?
No. Our migration process is designed for zero downtime. We use a staged approach with background sync and a fast cutover, ensuring no disruption to your live business operations.
How do I validate that everything migrated correctly?
Every client receives a Migration Validation Report with comprehensive metrics including record-count parity, attachment integrity verification via checksum, and full audit logs. We also offer unlimited sample migrations so you can verify before committing.
Do I need professional help for this migration?
While simple migrations can sometimes be handled in-house, professional help ensures zero data loss, proper field mapping, and preservation of relationships between records. Our engineer-led approach catches edge cases that automated tools miss.
Does ClonePartner provide guidance before committing?
Yes. We provide a free consultation and assessment. We'll review your data structure, discuss your requirements, and provide a detailed migration plan and fixed-price quote before you commit to anything.
Is migration pricing a flat fee, or does it scale with data volume?
It's a flat fee based on the scope estimate you give us — small variances in actual volume (a bit more or less) don't change the price.
Can we whitelist a single IP instead of opening our network to your migration tool?
Yes — all migration traffic runs through a centralized system using one fixed IP, which your IT team can whitelist instead of opening broader network access.
Will original ownership and authorship on tickets and articles be preserved?
Yes — ownership, author, and created-time metadata are preserved. Where the target doesn't have a native owner field (e.g. tickets becoming list items), this is carried as embedded metadata on the migrated record.
What support do you provide after the migration goes live?
At ClonePartner, we consider ourselves your partners in this journey. We take full accountability for your migration's success. Once your migration goes live, we provide 30 days of comprehensive post-migration support. During this period, we will assist with everything needed to ensure your transition is a complete success.
Will we get a migration report and a ticket-mapping sheet linking old ticket IDs to new ones?
Yes. We provide a comprehensive migration report along with a ticket-mapping sheet that links each old ticket ID to its corresponding new ticket ID. This ensures full traceability, simplifies post-migration verification, and helps your team validate that tickets have been migrated accurately.
After migration, do I contact ClonePartner or the platform's own support if something looks wrong?
ClonePartner is the contact for anything about the migrated data itself. Platform-level behavior — call routing, compose-window UI, and similar configuration — is handled by the destination platform's own support.
If the new system can't natively support an old record type, what are my options?
We handle it case by case: map it to the closest native object, create a custom field or object, fold it into the parent record as text or an internal note, attach it as a file, or keep it in a read-only archive. You see how your chosen approach looks in a sample migration before we run the full set.
Will we get a report showing exactly what migrated versus what didn't?
Yes. You get a final reconciliation report comparing source and target counts for every object.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
