A Phased Migration from a Legacy CMS with Zero Downtime
Overview
The Challenge
Keeping the new CMS in sync with the legacy system would have required ongoing dual-publishing or complex migration scripts. A single “cutover day” was unacceptable to business leaders due to the risk of downtime and content freezes.
The Solution
The platform was migrated using a phased approach, running the legacy and new CMS in parallel while sections were incrementally cut over. This allowed for ongoing development, testing, and rollback without disruption.
Impact
- Without feeling rushed, we were able to offer more personalized training and get valuable feedback from teams as we migrated their sections of the website to the new CMS.
- The overall project cost was reduced, due to reduced reliance on (and retention of) external agencies.
- The only cutover required was DNS, which went smoothly.
Technical Approach
Architecture
A reverse proxy, written in C#, running on the old CMS, forwarding specific paths to the new CMS.
Tech Stack
Challenges & Solutions
Increased Latency
Forwarding traffic from a separate CMS introduced some latency, but not nearly as much as three reverse proxies did. To go international quickly, we utilized a SaaS product called Smartling, which translates pages in real-time by acting as a proxy. For example, a request to site.com/es-es/contact would reverse proxy to site.smartling.com/es-es/contact, which would look up the English version of the page at site.com/contact, and return the translated result. After introducing a second proxy, requests to international pages would be subjected to an additional hop. Although the added latency was unavoidable, increasing the cache duration greatly reduced the impact.
Path Collisions
Some resource paths would inevitably overlap. The first solution was to name folders differently, where possible. Luckily, the browser launches new requests for any dependencies defined in the HTML, which all go through the reverse proxy. This provided a lot of control over how we could resolve collisions. We could set cookies, look at the referer, and rewrite the returned HTML if there wasn’t a better solution.
The Sitemap
Most sitemaps are generated automatically, but with content split between two places, a special system needed to be implemented. A third-party tool was used to merge the sitemaps of both systems.
Stale Links
Certain parts of the site are frequently changed. For example, sometimes downloadable assets or event pages are taken down. If these pages are linked to in the new CMS, there are no automated checks that ensure the links get removed or updated. To avoid this, we decided to migrate the events, webinars, resources, and homepage in the final week before cutover.