Kentico to Drupal Migration

KEY CHALLENGES

What makes this migration complex

These are the architectural mismatches and technical hurdles specific to a Kentico to Drupal migration.

Most Critical

No Native Migration Path

Kentico's own Migration Tool targets only Xperience by Kentico as a destination and produces no output usable by Drupal, requiring a fully custom SQL extraction and Migrate API loading strategy.

Blocks all downstream imports if mapped wrong

Three-Table Content Extraction

Extracting a single Kentico page requires JOIN queries across CMS_Tree, CMS_Document, and a per-page-type coupled data table, with media assets adding a fourth source from CMS_Attachment or external blob storage.

Tree Hierarchy to Flat Nodes

Kentico's tree-based content hierarchy stored in CMS_Tree must be flattened into Drupal's non-hierarchical node model, with URL paths and navigation structure rebuilt separately using Menu Links or Taxonomy Terms.

Page Type to Content Type Remapping

Each Kentico page type maps to its own coupled data table with custom columns, requiring individual field-level analysis and explicit YAML process plugin mappings for every Drupal content type created.

Page Builder Widget Translation

Kentico's Page Builder widget layout is stored as a proprietary JSON payload in DocumentPageBuilderWidgets and has no direct equivalent in Drupal's content model, requiring manual re-architecture of structured layout content.

Chained Migration Dependency Order

Drupal's Migrate API requires multiple migration configurations executed in strict dependency order — taxonomy terms, then media and files, then users, then paragraphs, then nodes — making sequencing errors a common source of failed imports.

MIGRATION RISK ASSESSMENT

Every migration risk, already solved

Migration between platforms is full of edge cases. Our engineers have identified every risk from Kentico to Drupal and built proven solutions for each one.

High complexity

Pages (CMS_Tree / CMS_Document)

Every page requires a multi-table JOIN across at least three SQL Server tables, and the hierarchical tree structure must be manually reconstructed as flat Drupal nodes with separate menu or taxonomy relationships.

Solved
Coupled Page Type Fields

Each custom Kentico page type stores its fields in a uniquely named coupled data table, requiring individual schema analysis and a separate Migrate API YAML configuration per content type.

Solved
Page Builder Layouts

The Page Builder widget payload stored in DocumentPageBuilderWidgets is a proprietary JSON structure with no Drupal equivalent, meaning layout content cannot be automatically migrated and must be manually redesigned.

Solved

Custom engineering

Media Files and Attachments

Attachments stored in CMS_Attachment require individual fetches by GUID, and files stored in Azure Blob Storage or the filesystem add a separate binary transfer step that the REST API cannot handle in bulk.

Handled
Multilingual Content

Kentico stores one CMS_Document row per language per node, so multilingual sites require language-aware SQL extraction and Drupal's content translation system must be configured before migration runs execute.

Handled
URL Aliases and Redirects

Kentico's NodeAliasPath defines URL structure through the content tree, but Drupal does not inherit this automatically, requiring explicit mapping of alias patterns and a redirect import to preserve inbound links and SEO equity.

Handled
Users and Roles

Kentico's role and membership model differs from Drupal's permission system, requiring manual role mapping and password hashing translation since Kentico's password hashes are incompatible with Drupal's authentication layer.

Handled
Workflow and Publishing States

Kentico's workflow steps and document publishing states do not have a direct schema equivalent in Drupal's Content Moderation module, requiring manual state mapping and validation before go-live to avoid unintended public content exposure.

Handled

Clean transfer

Taxonomy Terms

Kentico categories and taxonomy can be extracted as flat SQL records and loaded into Drupal taxonomy vocabularies using a straightforward Migrate API configuration, but must be migrated before any dependent node migrations run.

Clean
Metadata Fields (SEO)

DocumentPageTitle and DocumentPageDescription are discrete columns in CMS_Document and map cleanly to Drupal's Metatag module fields via simple Migrate API process plugin assignments.

Clean

CUSTOM MIGRATION

Fully customizable engineer-led migration

Tailor your migration from Kentico to Drupal exactly to your needs with our flexible customization options. Our experts will configure the perfect migration plan for your business.

Migration Filters

Data Types

MIGRATION TIMELINE

Your Kentico to Drupal migration, step by step

See how long your migration will take from start to finish. Drag the slider to estimate based on your data volume.

How many records are you migrating?

<10K 50K 100K 250K 500K 1M 2M 5M 10M+

Checklist ~3 days

Sample 1 day

Review ~2 days

Full 2 days

Delta 1 day

Your team ClonePartner

Estimated total

~9 business days

Migration Checklist

1 day · ClonePartner ~2 days · Your team

We prepare the optimal data mapping as a shareable spreadsheet. Your team reviews, approves, and adds any customizations.

Sample Migration

1 day · ClonePartner

We run a test migration with a representative sample of your data to verify mapping accuracy and identify any potential issues before the full run.

Review & Approve

~2 days · Your team

Your team reviews the sample migration results, confirms data accuracy and mapping, and gives the go-ahead for the full migration.

Full Migration

2 days · ClonePartner

We execute the complete migration of all your data to your new Drupal, with real-time progress tracking and comprehensive logging.

Delta Migration

1 day · ClonePartner

We capture and transfer any new data that was added or updated during the main migration to ensure no data is lost. This final sync keeps everything current.

Feature / Criteria	ClonePartner	Automated Tools	CSV Import	In-house migration
Custom Scripting for complex data	✓ Engineers build & maintain	✗ No	⚠ Manual	✓ Yes – but costly
Sandbox & Pilot Migrations	✓ Full sandbox + pilot plans	⚠ Limited	✗ No	⚠ Often Informal
Manual validation & reconciliation	✓ Automated + manual QA	✗ No	✓ Yes (Manual)	✓ Heavy manual effort
Backup & rollback plan	✓ Robust procedures	✗ No	✗ No	⚠ Often incomplete
Handles automation and integrations	✓ Full support	⚠ Partial	✗ No	⚠ Possible but fragmented
Post-migration engineer support	✓ Dedicated engineers	✗ No	✗ No	⚠ Limited support
Adaptable to API changes	✓ Proactive adaptation	✗ No	⚠ Manual fixes	⚠ Slower response
Turnaround / timeline predictability	✓ Predictable timelines	⚠ Fast but brittle	⚠ Slow and manual	⚠ Often slower
Data Security & Compliance	✓ High – enterprise grade	⚠ Medium (depends)	⚠ Low (manual)	⚠ Hidden gaps common
Pricing predictability	✓ Transparent & fixed	⚠ Low (per-job)	⚠ Low (manual hours)	⚠ High/variable OPEX
End-to-end project management	✓ Full E2E delivery & PM	✗ No	✗ No	⚠ Often partial
Business impact & opportunity cost	✓ No diversion of staff	✗ No	✗ No	⚠ Diverts engineering

What does an Engineer-led migration mean anyway?

Speed & Accuracy: Our Blended Method

We blend automation (smart scripts, bulk APIs) with human expertise for speed without risk. Our engineers manually check every mapping, validation, and exception.

You get:

Speed of automation for bulk record migration
Precision of engineers verifying integrity and business logic
Pilot migrations and sandbox testing to catch issues early
Real-time validation reports and rollback readiness

Result: 50x faster migrations than manual imports — with near-zero error rates.

Handling the Tricky Tech and API Details

The Kentico and Drupal APIs each behave differently, which is where our engineers shine. We build custom logic to handle the data quirks where generic tools typically break.

We handcraft API logic for:

Field mapping and transformation
Pagination, rate-limit handling, and throttling
Preserving content relationships, media, and revision history
Syncing custom fields, taxonomies, and templates without breaking structure

Our scripts: Natively retry failed calls, re-queue large attachments, and ensure data parity.

No Guesswork

We don't just promise smooth migrations—we measure and prove them. Every client receives a Migration Validation Report with all metrics.

Typical results across projects:

100% record-count parity between your Kentico data and Drupal
Zero downtime during staged cutovers
99.9% attachment integrity (verified via checksum)
Full automation and preservation of all business rules

Our standard: Includes full SEO and redirect preservation and 30 days of engineer-assigned support post go-live.

We Adapt to Your Setup (Not the Other Way Around)

No two teams configure Kentico or Drupal exactly the same way—with unique content models and data. We customize every migration script to fit your exact workflow, taxonomies, and templates.

Our engineers adapt for:

Custom fields, content types, and workflows
Multi-site or multi-language setups
Historical imports and partial (date-based) migrations
Integration re-mapping for search, analytics, or forms tools

The promise: If your data doesn't fit a standard template, we build one just for you.

FAQ

Frequently Asked Questions

Everything you need to know about migrating from Kentico to Drupal. Can't find what you're looking for? Talk to our team.

Kentico → Drupal 6 Before you start 2 Data & mapping 2 Timeline & downtime 3 Security & access 1 Pricing 1 After go-live 5

Still have questions?

Book a free 30-minute consultation with our team.

Contact our team

Kentico → Drupal

6 questions

Which Kentico entities don't migrate cleanly to Drupal, and what do we need to do about them?

Four entity types land in Drupal through workarounds rather than direct equivalents. URL redirects and aliases map to Drupal's Path Alias, but redirect rules map better to the Redirect contributed module, which must be installed before migration. Page attachments are stored as Drupal File entities and linked via a field, so the field must exist on the target content type first. Kentico headless Content Items have no native counterpart in Drupal and are mapped to standard Nodes, meaning any headless-specific delivery logic must be rebuilt separately. Web parts and widgets are partially replicated as Drupal Custom Blocks, but because widget configuration is tightly coupled to .NET code it cannot be ported—layout and behavior must be reconfigured by hand in Drupal after the data lands.

Does the Kentico version matter, and which API does ClonePartner use to read the source data?

Yes, the API surface differs significantly across versions. Xperience by Kentico (the current SaaS-first product) has the most complete REST Management API. Kentico Xperience 13 and earlier rely heavily on the .NET CMS.DataEngine for bulk operations rather than REST, which affects how data is extracted. Versions 12 and older are already out of Kentico's support, and Kentico Xperience 13 itself reaches end of all support on 1 January 2027, so the scoping call will confirm which extraction path applies to your specific version and instance configuration.

What happens to Kentico form submissions during migration—can they be moved to Drupal Webform?

Kentico BizForms map to Drupal Webform and form submissions map to Webform Submission entities, but there is a significant extraction constraint on the Kentico side: form submission data is not accessible via the standard public API and requires either direct database access or a custom endpoint on the source instance. ClonePartner scopes this during the discovery call to confirm what access is available; without database-level or custom API access, submission records cannot be read from Kentico and the migration scope would need to be adjusted.

Will all our Kentico users and passwords carry over to Drupal?

User accounts, roles, and role assignments migrate directly from Kentico to Drupal. Passwords do not transfer: Kentico does not expose password hashes through its API, and Drupal stores passwords in its own hashing format that cannot accept plaintext values even if they were available. Every migrated user will need to perform a password reset in Drupal before they can log in, so a post-cutover communication plan for your user base is a required step in the project.

Do we need to set up Drupal content types and fields before the migration runs, or does ClonePartner create them?

ClonePartner migrates content and data; it does not build or configure your Drupal application. Kentico custom page type definitions must be replicated as Drupal content types with matching fields before content records can be imported, because entity reference fields and paragraph structures must exist on the target before relational records can be linked. Drupal configuration entities—content types, fields, and vocabularies—are best created via Drupal's config sync (YAML export/import) by your development team, not through JSON:API. The scoping call identifies the full list of types and fields required so your team can prepare the target environment before ClonePartner begins the data transfer.

What silently gets left behind if we don't plan for it before migrating from Kentico to Drupal?

Several categories of data can be lost without explicit planning. Relationships between pages and categories must be re-established after both sides are migrated, because the links are a separate step rather than an automatic outcome of migrating each entity. Media files stored in cloud locations (rather than Kentico's local filesystem) are not readable by the extraction layer and must be downloaded to local storage first. Workflow history and audit logs are not portable via the public API and will not appear in Drupal. Multilingual content requires the Language and Content Translation modules to be installed and configured in Drupal in advance; without them, translated variants cannot be imported and would be silently skipped.

Before you start

2 questions

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.

Data & mapping

2 questions

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.

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.

Timeline & downtime

3 questions

How long does the Kentico to Drupal 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 Drupal?

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.

Security & access

1 question

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.

Pricing

1 question

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.

After go-live

5 questions

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.

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.

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.

Migrate from Kentico to Drupal with precision & ease

Why teams migrate from Kentico to Drupal