How an academic medical center launched its full site on schedule, with the content migration still running

Challenges

Every big website rebuild hits the same wall. Years of content take months to move, but the launch date won't wait. And while the move is happening, people can lose access to the very information the site exists to give them.

Move everything first, and the launch date slips. Launch in phases, and visitors hit broken pages wherever the content hasn't caught up. On a site like this, a broken page isn't a small flaw. It's a person who came looking for care and couldn't find it.

Approach

We separated the launch from the migration, so neither had to wait for the other. Instead of holding the new site back until every page had moved, we let it go live and kept the migration running behind it.

The visitor saw one finished site and never knew part of it was still being moved.

Because the two ran side by side, the launch date no longer depended on the migration finishing. The site could go live on the day it was promised, and the content migration could keep moving at its own pace.

Solution

Pages that don't break

When a visitor opened a page that had not been migrated yet, a handler caught it and pulled the matching page from the old site. The old headers and footers were stripped away, and the content was placed inside the new design. The visitor reached the page they came for and saw one consistent site, with everything they needed still there.

Three page types, cleaned up

The old site had been built three different ways: a modern template, department pages, and calendar pages. Each type ran through its own plugin, which recognized the layout and cleaned it up correctly. Old styles were rewritten so they could not bleed into the new design. Inline scripts were restructured to run safely. Old links were rewritten so they worked inside the new site.

Migration without a cutover

As each page moved into the new site, the new version took over on its own. There was no cutover to schedule and no redirects to manage. The old site receded page by page as the migration went on.

Caching under load

Proxied pages were cached, so the old server was asked once per page rather than on every visit. When several people opened the same cold page at the same time, a lock made sure it was fetched once, not many times over. Each page followed the old server's own cache timing.

Findable in search

Breadcrumbs were built from menus, page details were pulled from the old pages, and sitemaps were generated automatically. The proxied pages were indexed for search, and old links were redirected from one place. Someone searching for clinical content found it whether or not it had moved yet, and so did Google.

Two connected platforms

The public College of Medicine site and a central content hub ran from one source. Editorial teams published once in the hub, and the content appeared across every connected site on its own.

Consistent and safe to ship

A shared component library in Storybook kept both platforms consistent as they grew. Akamai served the pages from servers close to each visitor and cleared its stored copy the moment content was published, so no one saw an old version. Every release was reviewed and tested before it went out.

Outcome

The new site went live on the day it was promised, with every page working and the migration still running quietly behind it. A patient looking for a clinical trial found it. A doctor searching the physician directory reached the right profile. A student reading about the college saw a finished site. No one landed on a broken page, and no one could tell which parts had already moved and which had not.

For the people who run the site, one ecosystem replaced a scattered one. Two platforms now publish from a single hub, so a team writes something once, and it appears everywhere it should. The old site keeps receding on its own as each page moves across, with no cutover to schedule and no rollback to fear.

And the health system got back something it had lost: control of its own timeline. It can rebuild and relaunch on a date it chooses, without asking visitors to pay for the transition. The slowest corner of a years-deep content estate no longer decides when the site can go live.