Migrating OpenText Web (TeamSite) to Contentstack
Project Spotlight: moving more than 400 pages, 4,000 assets and a Spanish locale into a headless CMS with our Automated CMS Migration tool.
A New CMS Is Only as Good as the Content in It
Our client, a large Southwestern U.S. utility, was moving its website from OpenText Web (TeamSite) to Contentstack, a headless CMS. That meant not only migrating the content but replatforming the front end too: the existing site ran on LiveSite Display Services, a Java application on Tomcat that rendered pages from XSL presentation templates, while the new architecture used Next.js, a React framework, for the front end. A key requirement was to preserve the existing website experience without any noticeable changes to the look and feel of the pages. Additionally, all existing URLs had to remain unchanged to avoid negatively impacting SEO and search engine rankings.
We used our Automated CMS Migration tool, which works backward from the existing live website. It systematically analyzed the front end, page by page, to identify the content structure and derive the content model. Using these content models, we rebuilt the front end in Next.js while preserving the existing page designs, Adobe Analytics tracking, and structured data. The tool also automated the creation of content entries in Contentstack through its Content Management API, and carried over the marketing team's redirect rules. When the site went live, every page answered at the same address it had before.
At a Glance
400+ Pages, 4,000 Assets
Every page became structured Contentstack entries, and every image and document reference was relinked to its uploaded asset.
Modeled on the Live Site
Content types were derived from the live site's components. Shared components became reusable, and duplicated content now lives in one place.
English and Spanish
The Spanish site moved as a Contentstack locale linked to its English source, not as a separate copy of the site.
Same URLs, Same Redirects
Every page kept its URL, so links and search rankings were untouched. The marketing team's redirect rules came across too.
Front End Rebuilt in Next.js
The Java and XSL rendering on LiveSite Display Services was replaced by Next.js (React) components that read their content from Contentstack, with the page design unchanged.
Analytics and SEO Intact
Adobe Analytics tracking and the JSON-LD structured data search engines read were carried into the new front end.
The Challenge: Two Different Content Models
OpenText Web (TeamSite)
Content lives in Content Items (long known as DCRs, data content records): XML files built from data capture templates, which presentation templates publish as finished pages.
Contentstack
Content lives as JSON entries in typed content types, with assets and references to other entries stored as separate, linked objects.
Copying Was Not an Option
Each page had to be broken into fields, each image and document reference rewritten to point at the uploaded asset, and each Spanish page linked to the English page it translates.
No One-to-One Mapping
The two platforms model content differently, so the Contentstack content types had to be designed from scratch before any content could be loaded.
Thousands of References
Pages pointed to images, PDFs and other pages by TeamSite path. Every one of those had to resolve to a Contentstack asset or entry.
Nothing Visible Could Change
Every page had to keep its URL and its design, every redirect the marketing team relied on had to keep working, and analytics and structured data had to report exactly as before.
How the Migration Worked
We worked backward, from the front end to the content. TeamSite and Contentstack structure content types in different ways, so copying the Content Items field for field would have carried forward prior platform-specific design decisions into the new platform.
Read the Existing Front End
Our Automated CMS Migration tool went through every page of the live site and broke it down into the components it is built from.
Derive the Content Model
Those components became the Contentstack content types. Shared components became reusable content types, and content duplicated across templates now lives in one place.
Build the Next.js Front End
A small set of standard page templates, each a Contentstack content type, covers every kind of page on the site. Each template lets authors add one or more Modular Blocks, and each block maps to a Next.js component. We rebuilt every component on that model, recreating the existing page design.
Create the Entries
The tool loaded the content into Contentstack through its Content Management API, in a set order. It uploaded every image and document first, recording each asset's original TeamSite path alongside its new location in Contentstack. It then created the pages as entries, using that record to point every reference at the new asset or entry. Finally, the Spanish pages were added as localized versions of their English entries.
What We Took Away
- Model first, migrate second. The content types decide what every page becomes. Getting them right before loading anything kept the migration from being redone.
- Assets before entries. Uploading assets first and keeping a map of old paths to new ones made it possible to rewrite every reference in a single pass.
- Localization is a relationship, not a copy. Linking each Spanish page to its English source keeps the two languages in step after go-live.
- Visitors shouldn't notice the move. Keeping every URL meant search rankings and inbound links carried over. Migrating the redirect rules meant marketing's existing campaign and vanity links kept working.