What happens to my Kentico custom page types when they move to Plone?
Custom Kentico page types (Document Types) map to Plone's generic Page content type, not to equivalent custom Dexterity types. This means any fields specific to your custom types — and the structured layout they enforce — will not survive the migration as discrete fields. Before the migration runs, your team needs to recreate the corresponding Dexterity content type definitions on the target Plone instance; ClonePartner can then populate those types, but defining them is outside the scope of data migration.
Do user passwords carry over from Kentico to Plone?
No — neither platform exposes hashed passwords through their APIs, so passwords cannot be exported from Kentico or imported into Plone. Users, roles, and group memberships migrate correctly, but every account will require a password reset on the Plone side before the user can log in. If your organisation uses LDAP or an SSO provider, connecting Plone to that identity source after migration eliminates the need for individual resets.
Which Kentico version do I need before starting the migration?
The API surface varies significantly by Kentico version. Xperience by Kentico (the current SaaS-first product) has the most complete REST Management API, making programmatic content export straightforward. Kentico Xperience 13 and earlier rely heavily on the .NET CMS.DataEngine rather than REST for bulk operations, which requires a different extraction approach; Kentico 13 also reaches end of technical support on 31 December 2026, with all security repairs ceasing from 1 January 2027. During your scoping call, confirm your exact version so the correct extraction method is planned from the start.
Will my Kentico web parts and widgets come across to Plone?
No — Kentico web part and widget configurations are tightly coupled to .NET assemblies and have no equivalent in Plone's architecture. They are not portable and will not appear on the migrated pages. The content that lives inside those widgets (text, images, files) is migrated where the API exposes it, but any presentation logic, component layout, or dynamic behaviour the widgets provide must be rebuilt in Plone using portlets, viewlets, or Plone add-ons by your development team.
What Plone-side setup has to be done before content can be imported?
Three things must exist on the target Plone instance before ClonePartner begins import: custom Dexterity content type definitions that correspond to your Kentico page types, the user and group accounts that local role assignments reference, and — if your content is multilingual — plone.app.multilingual must be installed and configured. Attempting to import content before these are in place causes referential integrity failures and orphaned permission records. ClonePartner's pre-migration checklist covers each of these prerequisites during scoping.
Is Kentico form submission data included in the migration to Plone?
Form submission data cannot be exported via Kentico's standard API; moving it requires direct database access or custom endpoints, which ClonePartner scopes on a case-by-case basis. Similarly, workflow history, audit logs, and page revision history are not exportable from Kentico through public APIs, and Plone's CMFEditions revision history is not importable via REST on the target side. If preserving submission records is a compliance requirement, raise it during the scoping call so the approach — typically a direct database extract — can be planned and priced into the project.
How long does the Kentico to Plone 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 Plone?
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
