Case study # How an academic medical center launched its full site on schedule, with the content migration still running ![How an academic medical center launched its full site on schedule, with the content migration still running](/sites/default/files/clone-images/6a4cf1ad27a75e95d9046f09_cover_4_3597fad9.webp) Industry Healthcare Location United States Engagement 1 Year Focus Launch a new Drupal platform while a years-old content estate continued migrating in the background so that visitors could move across migrated and unmigrated pages as one continuous site Services Platform Engineering Content Architecture Drupal on Acquia Search and SEO CI/CD This is the website where people come to find care and new research. So when this health system decided to rebuild it, the real risk was not a technical one. It was a patient who couldn't find the right clinical trial while the site was being rebuilt. The site is the front door to the College of Medicine and its care services. It holds the physician directory people search, the clinical trials they look up, the research newsroom, and the pages patients rely on. Behind all of it sat an older site with years of content that couldn't move overnight. QED42 built and launched the new site on time, with every page working, while the old content moved across in the background. Nothing broke. Nothing hit a dead end. ![Clinical laboratory testing supporting medical research](/sites/default/files/clone-images/6a4cef7d9590bb76e4c3d8c8_image_grid_mockup_01_5e20ce7b.png) ![Academic medical center campus building](/sites/default/files/clone-images/6a4cef83abd85e61e939ddff_image_grid_mockup_02_98f163cf.png) ![Drupal platform migration and content integration illustration](/sites/default/files/clone-images/6a4cef8707d050f3f620a1fa_image_grid_mockup_03_1c94579a.png) ![Medical center leadership announcing the new digital platform](/sites/default/files/clone-images/6a4e0274b90029b4f457ea6b_image_grid_mockup_04_f3410d70.png) ## 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. ![Legacy and new website content displayed in one unified interface](/sites/default/files/clone-images/6a4e017457130f761877a57c_Frame_2147203223_4f855960.png) ## 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. ![Content proxy serving unmigrated pages inside the new Drupal website](/sites/default/files/clone-images/6a4d00936868fd747719eb60_17_1_741be32c.png) ## 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. ![Automatic migration from legacy pages to native Drupal content](/sites/default/files/clone-images/6a4e23b2e129a19e402c7ce2_Frame_2147203226_1_1_c9e07e12.webp) ### 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. ![Caching layer for proxied legacy content](/sites/default/files/clone-images/6a4e021257130f7618780f56_ert_2_073f7956.webp) ### 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. ![Caching layer serving proxied legacy pages](/sites/default/files/clone-images/6a4d000e035e6ca4dec8296a_re_1_9d164447.png) ### 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. ![Search indexing and sitemap generation during content migration](/sites/default/files/clone-images/6a4e03b525033b6398d3defc_17-1_1_74193fff.webp) ### 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. ![Clinical trials search interface](/sites/default/files/clone-images/6a4e233e4ea93526bbe8da88_12_0855fb1f.png) ## 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. {"@context":"https://schema.org","@type":"FAQPage","@id":"https://qed42.com/work/how-an-academic-medical-center-launched-its-full-site-on-schedule-with-the-content-migration-still-running#faq","isPartOf":{"@id":"https://qed42.com/work/how-an-academic-medical-center-launched-its-full-site-on-schedule-with-the-content-migration-still-running#webpage"},"mainEntity":[{"@type":"Question","name":"How do you launch a new website while content is still migrating?","acceptedAnswer":{"@type":"Answer","text":"By separating the launch from the migration so neither waits for the other. The new site goes live on its date, and a reverse-proxy handler serves any not-yet-migrated page inside the new design. Visitors see one continuous site. For this academic medical center, the platform launched on schedule with the migration still running behind it."}},{"@type":"Question","name":"What happens when a visitor opens a page that has not migrated yet?","acceptedAnswer":{"@type":"Answer","text":"A handler catches the request and pulls the matching page from the old site, strips its old headers and footers, and places the content inside the new design. Old styles are rewritten so they cannot bleed in, inline scripts are made safe, and old links are rewritten to work in the new site. The visitor reaches the page they came for and sees one consistent experience."}},{"@type":"Question","name":"How do you keep search working during a phased migration?","acceptedAnswer":{"@type":"Answer","text":"Breadcrumbs are built from menus, page details are pulled from the old pages, and sitemaps are generated automatically. Proxied pages are indexed and old links redirect from one place, so someone searching for clinical content finds it whether or not it has moved yet, and so does Google."}},{"@type":"Question","name":"Do you have to do anything special when a page finishes migrating?","acceptedAnswer":{"@type":"Answer","text":"Nothing. The moment a migrated page gets a Drupal path alias, the proxy entry for that path is deleted automatically and Drupal starts serving it natively. No redirects to update, no flags to flip, no cache to manually clear. The old site recedes page by page as migration progresses, invisibly to visitors."}}]} ## Frequently asked questions ### How do you launch a new website while content is still migrating? By separating the launch from the migration so neither waits for the other. The new site goes live on its date, and a reverse-proxy handler serves any not-yet-migrated page inside the new design. Visitors see one continuous site. For this academic medical center, the platform launched on schedule with the migration still running behind it. ### What happens when a visitor opens a page that has not migrated yet? A handler catches the request and pulls the matching page from the old site, strips its old headers and footers, and places the content inside the new design. Old styles are rewritten so they cannot bleed in, inline scripts are made safe, and old links are rewritten to work in the new site. The visitor reaches the page they came for and sees one consistent experience. ### How do you keep search working during a phased migration? Breadcrumbs are built from menus, page details are pulled from the old pages, and sitemaps are generated automatically. Proxied pages are indexed and old links redirect from one place, so someone searching for clinical content finds it whether or not it has moved yet, and so does Google. ### Do you have to do anything special when a page finishes migrating? Nothing. The moment a migrated page gets a Drupal path alias, the proxy entry for that path is deleted automatically and Drupal starts serving it natively. No redirects to update, no flags to flip, no cache to manually clear. The old site recedes page by page as migration progresses, invisibly to visitors. ## Bring us your challenge We’ll help you get clear on what needs solving, that’s where we begin You must have JavaScript enabled to use this form. Name Email Phone number Company name Message Attach brief *Supported formats are PDF, Doc, JPG in 4mb max. Yes, I'd like to hear from QED42 about our work, events, and updates. Privacy Notice Leave this field blank Next case study [ ![](/sites/default/files/clone-images/6a4fa59e5ec05a8cc267016b_cover_5_ff2f8a28.webp) ### How a pharmaceutical company runs regulated content across 5 markets from 1 governed platform ](/work/how-a-pharmaceutical-company-runs-regulated-content-across-5-markets-from-1-governed-platform)