Oracle WebCenter to Kentico Migration: A Practical Guide for Enterprise Teams

Migrating from Oracle WebCenter to Kentico is an enterprise CMS replatforming project, not a one-click content conversion. It typically requires content inventory and mapping, custom functionality redevelopment, integration validation, and deliberate SEO preservation before a controlled launch. This guide walks through what an Oracle WebCenter to Kentico migration actually involves, based on how Oracle WebCenter and Xperience by Kentico are structured today.

This article covers what makes an Oracle WebCenter to Kentico migration complex, the core ideas behind a sound migration strategy, two contrasting approaches to the project, a practical comparison of what changes between the platforms, and the trade-offs worth weighing before committing to a scope or timeline. It closes with a comparison table, five frequently asked questions, and a summary of what a completed migration should deliver.

The Problem With Oracle WebCenter

Oracle WebCenter is not a single product. It's a family that includes WebCenter Content (an enterprise content repository), WebCenter Sites (a web content management system for building and publishing large-scale sites), and WebCenter Portal (for transactional and collaborative web applications). Depending on which components an organization uses and how they were customized, the challenges below will apply to different degrees.

1. Legacy architecture and deployment model. Oracle's own documentation describes WebCenter Content Server as deployed to an Oracle WebLogic Server domain, with WebCenter also able to run on IBM WebSphere. This gives the platform a Java EE, service-oriented architecture where every request is processed as a service handled by an underlying repository. Migrating away from this stack means separating the content management function from the middleware it depends on.
2. Custom components and site-specific logic. Many WebCenter Sites implementations include custom Java components, flex family definitions, and site-specific templates accumulated over years of use. These customizations rarely have a direct equivalent in another platform and typically need to be re-analyzed and rebuilt rather than converted automatically.
3. Complex or inconsistent content structures. WebCenter Content organizes content using profiles, metadata fields, and taxonomies that often evolve organically over time. Content Categorizer, for example, supports multiple taxonomies and third-party categorization engines, which means large organizations can end up with several overlapping ways of structuring similar content. This structure needs review before it can be mapped anywhere.
4. Integration dependencies. WebCenter installations are frequently connected to other Oracle Fusion Middleware components, identity management systems, ERP platforms, or SOA Suite processes. Each integration has its own authentication method and data contract that has to be documented before it can be rebuilt against a new platform.
5. Content portability. Content in the WebCenter Content repository carries metadata, versioning, and rendition information tied to the platform's own data model. Exporting this content is possible, but the result usually needs meaningful transformation before it fits a different content model. Pages and layout in WebCenter Sites do not map one-to-one onto pages and layout in another CMS.
6. SEO risk during the transition. Search engines index specific URLs, rendered HTML, and metadata. Recreating a WebCenter Sites URL structure without a deliberate redirect plan is one of the most common causes of organic-traffic loss during any CMS migration.
7. Media and digital asset dependencies. Digital assets in WebCenter often carry renditions, embedded metadata, and references from other content items. Media needs to migrate with those relationships intact, not just as flat files, or the content that references it will break.
8. Frontend redevelopment. WebCenter Sites renders pages through its own template language and asset model. None of that frontend logic can be reused directly in an ASP.NET Core-based platform, so templates and page layouts generally need to be rebuilt against the destination platform's own templating and component model.
9. Workflow and permissions differences. Content approval workflows and role-based permissions in WebCenter are tied to Oracle's own security and workflow infrastructure. These need to be re-modeled in the destination platform rather than copied configuration-for-configuration.
10. Testing complexity. Because a migration touches content, custom functionality, integrations, and SEO at the same time, testing has to validate all of these areas together instead of treating them as separate, unrelated work streams.

The Core Idea

1. Assess before migrating. A structured discovery phase (reviewing the existing WebCenter implementation, content volume, customizations, and integrations) should happen before any migration scope or timeline is finalized. Depending on the existing implementation, this assessment can surface work that isn't visible from the outside, such as undocumented integrations or unused legacy content types.
2. Map content instead of blindly copying it. Content should be mapped from the source content model to a target content model in Xperience by Kentico field by field, rather than exported and imported as-is. This determines how existing WebCenter content types and metadata correspond to content types defined in Xperience's Content Types application.
3. Separate content migration from code migration. Moving content and rebuilding functionality are different workstreams with different risks. Treating them separately makes each easier to test independently and reduces the chance that a content data issue gets mistaken for a code defect, or the reverse.
4. Rebuild functionality where necessary. Custom WebCenter components, workflows, and integrations built in Java generally cannot be converted directly into Xperience by Kentico's ASP.NET Core environment. The exact approach depends on what each piece of functionality does. Some can be replaced with built-in Xperience features, while others require custom redevelopment, which is where experienced enterprise CMS development support tends to matter most.
5. Preserve SEO deliberately. URL structure, metadata, and redirect mapping need to be planned as part of the migration, not addressed after launch. This starts with a complete URL inventory of the existing WebCenter site mapped to its Xperience equivalent.
6. Validate integrations. Every system connected to WebCenter (identity providers, marketing tools, ERP systems, search) needs to be re-validated against Xperience's GraphQL headless API, its primary integration API, or against custom .NET integration code, since the underlying protocols and authentication models will likely differ.
7. Use staged migration and testing. Migrating and testing content, functionality, and integrations in stages, rather than attempting a single cutover, reduces the risk of discovering major issues right before launch.
8. Design the target architecture intentionally. The migration is an opportunity to define how content should be structured across Xperience by Kentico's Content Hub and website channels, rather than defaulting to the same structure WebCenter used. This includes deciding what belongs in reusable content types versus page-specific content types, a distinction Kentico's own content modeling documentation describes as the difference between page-driven editing and structured, presentation-agnostic Content Hub data. It's covered in more depth in DotStark's overview of Xperience by Kentico's content architecture.

Journey One: The Traditional Migration Approach

This is the approach many teams default to without meaning to. It isn't wrong so much as risky when applied to a platform as different from Xperience by Kentico as Oracle WebCenter.

Step 1: Export everything

The instinct is to export all content, media, and metadata from WebCenter in bulk and treat the migration as an import job. This works for simple, flat content, but it skips the question of whether the source content model should even be preserved in the destination system.

Step 2: Recreate the old structure

Reproducing the WebCenter site tree, content types, and taxonomy one-to-one in Xperience feels safer, but it carries legacy complexity directly into the new platform, including structures that existed only to work around WebCenter's own limitations.

Step 3: Rebuild pages individually

Without a defined content model, pages tend to get rebuilt one at a time, each with its own layout decisions. This creates inconsistency across the site and multiplies the manual effort required, since nothing is templated or reused.

Step 4: Handle SEO at the end

Treating URL mapping, redirects, and metadata as a final cleanup step, rather than planning them alongside content mapping, is one of the most common causes of avoidable ranking and traffic loss after launch.

Step 5: Test shortly before launch

Compressing functional, content, integration, and SEO testing into the final days before go-live leaves little room to fix anything discovered late, and increases the odds of an unstable launch.

Journey Two: The Better Migration Approach

Step 1: Discovery and inventory

Before any migration work starts, build a complete inventory of pages, content types, media, URLs, metadata, workflows, users and roles, custom functionality, integrations, site search, analytics, and forms. This inventory becomes the reference point for every later decision.

Step 2: Architecture mapping

For every item in the inventory, decide whether it should be migrated as-is, transformed, consolidated with similar content, rebuilt from scratch, or retired entirely. Not every page or content type from the WebCenter site needs to exist in the new one.

Step 3: Define the target Kentico architecture

Design the destination content model, page structure, reusable content types, Page Builder components, media organization, navigation, workflows, and integration points in Xperience by Kentico before migrating content into it. This is also the stage where a structured CMS migration approach is defined for the project, rather than left implicit.

Step 4: Build the migration process

Structured content transformation and validation scripts reduce uncontrolled manual work compared to ad hoc copy-paste migration. Kentico publishes an official Migration Toolkit for moving from Kentico Xperience 13 to Xperience by Kentico; no dedicated, vendor-supported tool currently exists specifically for Oracle WebCenter to Xperience by Kentico migrations, so this step normally involves custom scripting and transformation logic built around the content mapping from Step 2.

Step 5: Rebuild custom functionality

Custom WebCenter functionality, including components, workflows, and integrations, needs individual analysis and redevelopment rather than direct code conversion, since the two platforms use fundamentally different languages and application frameworks.

Step 6: Migrate content and assets

Move content and media into the target Xperience structure, then reconcile counts, spot-check content fidelity, and validate that media relationships and metadata survived the transformation.

Step 7: Perform SEO migration

Complete the URL inventory, build the redirect map, migrate metadata and canonical tags, generate an updated XML sitemap, update internal links to point at new URLs, add structured data where applicable, and prepare to monitor the transition in Google Search Console once the site is live. Google's own site-move guidance recommends mapping every existing URL to its new destination and using 301 redirects rather than temporary ones, since search engines need to reassess and re-index changed URLs.

Step 8: Test

Testing should cover functional behavior, content validation, responsive rendering, integration testing, SEO checks, performance, and accessibility where applicable, plus redirect testing, ideally run against a staging environment that mirrors production.

Step 9: Controlled launch

Launch from a staging environment with a defined content freeze window, execute the final content migration, deploy, update DNS if applicable, and monitor crawl behavior, error logs, and traffic on both the old and new URLs, with a rollback plan ready in case of a major issue.

What Changes: Oracle WebCenter vs. Xperience by Kentico

What's Working Well

Structured content modeling. Defining content types deliberately in Xperience by Kentico's Content Hub, instead of mirroring WebCenter's existing structure, gives editorial teams a cleaner, more consistent content model to work with going forward.

Separating migration from redevelopment. Treating content migration and custom functionality rebuilding as distinct workstreams makes it easier to track progress, isolate defects, and test each piece independently.

Early SEO mapping. Building the URL inventory and redirect map alongside content mapping, rather than after development, gives the team enough lead time to validate redirects thoroughly before launch instead of rushing them.

Staged validation. Migrating and testing content and functionality in stages, rather than as one large cutover, surfaces problems earlier when they're cheaper to fix.

Honest Trade-offs

Migration is not automatic. There is no verified, vendor-supported tool that migrates content and functionality directly from Oracle WebCenter to Xperience by Kentico. The process depends on custom mapping, transformation, and validation work.

Custom functionality takes time. Any WebCenter component built in Java has to be re-analyzed and rebuilt for Xperience's ASP.NET Core environment. This is redevelopment work, not a configuration change, and it should be scoped accordingly.

SEO preservation requires planning. Redirects, metadata, and sitemap updates only protect search visibility if they're planned before launch, tested thoroughly, and monitored afterward. Skipping any of these steps increases the risk of losing rankings.

Content cleanup can increase scope. Reviewing WebCenter content for duplication, outdated pages, and inconsistent structure often expands the visible project scope, even though it reduces long-term maintenance burden.

Parallel systems increase temporary complexity. Running WebCenter and the new Xperience environment in parallel during a staged migration adds short-term operational overhead, including keeping both systems' content roughly in sync until cutover.

Surprising Decisions Worth Noting

• Not every page from the WebCenter site necessarily needs to be migrated. Some content may be outdated, duplicated, or no longer relevant to current business goals.
• Similar or overlapping WebCenter content types are sometimes better consolidated into a single Xperience content type rather than migrated as separate types.
• Preserving a URL is not the same as preserving the underlying page structure. A URL can stay the same while the content behind it is restructured entirely.
• Custom WebCenter functionality is sometimes better redesigned around Xperience's built-in capabilities than reproduced feature-for-feature.
• Media migration requires validation beyond copying files. Metadata, renditions, and content relationships all need to be checked individually.
• Defining the target content model before large-scale migration begins tends to prevent rework later in the project.
• A CMS migration often exposes content-governance issues, such as inconsistent metadata, unclear ownership, and outdated content, that existed in WebCenter but were never addressed.

The End Result

A well-executed Oracle WebCenter to Kentico migration should leave an organization with the content it actually needs preserved and reorganized around a maintainable content model, the necessary custom functionality rebuilt natively in Xperience by Kentico, integrations revalidated against the new platform's APIs, SEO signals deliberately carried over through redirects and metadata, content and functionality tested as a whole rather than in isolation, editors able to work efficiently in the new Content Hub and Page Builder tools, and a target architecture built to be maintained going forward rather than one that simply reproduces WebCenter's legacy structure.

Frequently Asked Questions

What is involved in migrating from Oracle WebCenter to Kentico?

An Oracle WebCenter to Kentico migration typically involves discovery and content inventory, content modeling and mapping, custom functionality redevelopment, integration validation, SEO migration including URL mapping and redirects, testing across content and functionality, and a controlled, staged launch. The exact scope depends on how the existing WebCenter environment was implemented and customized.

Can Oracle WebCenter content be directly imported into Kentico?

Not directly. Oracle WebCenter stores content using its own repository structure, metadata model, and content types, which do not map one-to-one onto Xperience by Kentico's content types and Content Hub. Content generally needs to be exported, transformed to match the target content model, and then imported and validated rather than copied as-is.

How do you protect SEO during an Oracle WebCenter to Kentico migration?

SEO protection requires a full URL inventory of the existing WebCenter site, a URL mapping to the new Xperience structure, 301 redirects for every changed URL, migrated metadata and canonical tags, an updated XML sitemap, and post-launch monitoring in Google Search Console. This planning should start early in the project rather than after development is complete.

What happens to custom Oracle WebCenter functionality?

Custom functionality built in WebCenter, such as Java components, flex family templates, or WebLogic-hosted services, generally cannot be converted directly into Xperience by Kentico's ASP.NET Core environment. Each custom feature needs to be analyzed individually and either rebuilt natively in Xperience, replaced with a built-in platform feature, handled through an integration, or retired if it is no longer needed.

How long does an Oracle WebCenter to Kentico migration take?

There is no fixed timeline for an Oracle WebCenter to Kentico migration. Duration depends on factors such as page and content volume, the complexity of custom functionality and integrations, data quality in the source system, how much of the process can be automated, and the scope of testing and redesign involved. Timelines should be estimated after a discovery and assessment phase, not before it.

Planning a WebCenter to Kentico Migration?

An Oracle WebCenter to Kentico migration touches content structure, custom functionality, integrations, and search visibility at the same time, which is why it benefits from being planned as a single, coordinated project rather than a series of disconnected tasks. If your team is assessing a move from Oracle WebCenter (whether WebCenter Content, WebCenter Sites, or WebCenter Portal) to Xperience by Kentico, DotStark's Kentico Silver Partner team can help with WebCenter assessment, content mapping, target architecture design, custom functionality redevelopment, SEO migration, and integration planning. For organizations weighing a broader enterprise digital transformation alongside the CMS move, that planning can happen as part of the same engagement.

Talk to DotStark about your Oracle WebCenter to Kentico migration