What a four-month healthcare site migration actually looks like

When a healthcare company asks me how long a site migration takes, the honest answer is three to five months for the build, plus two or three weeks of assessment before it, plus 60 days of support after launch. Four months is the middle of that range and it's what a typical project looks like: a health system or life-sciences company with 80 to 200 pages, a provider or product directory, a handful of forms, and a few integrations, moving off WordPress or an agency build onto Next.js and Sanity.

This post walks through those four months milestone by milestone. For each one I'll say what happens, what you get at the end of it, and what I need from you to get there. The last part is the one people underestimate. A migration is not something you hand off and wait for. There are specific things only your team can supply, and the timeline depends on when they arrive.

What happens before the build starts?

The assessment, and it sets everything that follows.

Before I quote a build, I spend two to three weeks inside your current site. I inventory every page, form, script, and integration. I pull your search data to find which URLs carry traffic and need protecting. I review performance, accessibility, and the compliance posture of your forms and analytics. I propose a content model for Sanity and write a migration plan with a risk register. At the end you get a written report, a recorded walkthrough, and a fixed price for the build.

The assessment is its own fixed-price engagement and it's credited against the build. I run it separately because it's the only way to give you a real number. Anyone who quotes a healthcare site migration without doing this work is guessing, and the guess is usually low.

What I need from you: one 45-minute kickoff call, then access. Your CMS, your analytics, your search console, your hosting. And the names of the people who will need to approve things later, especially in compliance and IT, so I can account for their review time in the plan.

Month one: what does the start look like?

The first month is about decisions and foundations, and it ends with your team able to see the shape of the new site.

In the first two weeks I finalize the content model with you. This is the list of content types the site is made of (service lines, conditions, providers, locations, news, and so on), what fields each one has, and how they relate. I go through it with you line by line, because this is the structure your team will live in for years. It's cheap to change now and expensive to change after content is migrated into it.

At the same time, your designer starts. I don't do visual design. You bring your own or I pair you with a design partner I've shipped with before, and either way the designer works from the content model so the designs and the structure match. By the end of month one the designer has a direction and I've built the foundation: the Sanity Studio configured for your content types, the Next.js project set up, hosting and environments in place, and the migration scripts written and tested against your existing content.

Milestone: start. The content model is signed off, the design direction is agreed, and you have a staging link that shows real migrated content in a rough layout. The first payment is due at this milestone.

What I need from you: decisions on the content model within a week of each review. Your brand guidelines and any existing design assets. An introduction to your compliance lead so I can walk them through the forms and analytics plan before anything is built. A decision on which old pages are being retired rather than migrated.

Month two: what gets built?

The pages, the components, and the integrations, in that order.

This is the most visible month. The designer delivers page designs and I implement them as a design system in code: a set of components that every page is built from, so the site is consistent and your team can't produce an off-brand page by accident. Each content type gets its templates. The provider directory gets its filters. The location pages get their maps.

Integrations happen here too. The appointment request form connects to your scheduling system or CRM. The careers page pulls from your applicant tracking system. The newsletter signup goes to your marketing platform. Each of these involves a vendor on your side, and each one is where timelines slip if the vendor is slow, so I start them early and I'll tell you in the weekly update when one is waiting on someone.

Compliance review starts in earnest. Every form is documented: what it collects, where it sends the data, who is notified, and whether that path is covered by a business associate agreement. The consent gate for analytics is built and your compliance team can see exactly what loads before and after a visitor agrees. I'd rather get a no from legal in month two than in month four.

What I need from you: the designer's deliverables on schedule, which usually means your team reviewing designs within a few days of receiving them. Contacts at each vendor I'm integrating with, and someone on your side who can chase them. Your compliance team's review of the forms and analytics plan, with a written sign-off. And the start of content work, which is the subject of the next section.

When does content get migrated?

It's happening the whole time, but the heavy lifting is in months two and three, and it's the part your team owns most.

The migration script moves your existing content into Sanity automatically. That gets the bulk across, but it doesn't make it good. Old sites accumulate pages that are outdated, duplicated, written for the wrong audience, or simply wrong. The assessment will have flagged these, and someone on your team has to decide what to do with each one: keep, rewrite, or retire.

For most healthcare sites this is the single biggest block of client work in the project. A 150-page site might have 40 pages that need a real editorial pass. Physician bios need checking. Service descriptions need updating. Condition pages written in 2018 need a clinician to confirm they're still accurate. I can't do any of that, and the project can't launch until it's done.

What I need from you: a named content owner with the authority to make decisions and the time to make them. A realistic estimate of how many pages need rewriting and who is doing it. A clinical reviewer if any of the content is medical. And a schedule, because "we'll get to it" is how launch dates move.

Month three: what does staging sign-off mean?

It means the site is complete on a staging URL and your team has agreed it's ready to launch, pending final content.

By the end of month three, every page template exists, every integration works end to end, every form has been reviewed and approved, and the content migration is complete in structure even if some pages are still being edited. I run the accessibility audit against WCAG and fix what it finds. I run performance testing and confirm the site meets the budget set at the start. I set up the redirect map: every URL from the old site that carries traffic points to its new home, and you can read the list.

Then I hand your team the Studio and train them. A recorded walkthrough, a written guide, and a live session where your editors add a provider, publish a page, and roll back a change. The point is that by launch your team has already used the CMS, not that they'll learn it after.

Milestone: staging sign-off. You've reviewed the complete site, your compliance team has signed off on forms and analytics, and you've confirmed the redirect map. The second payment is due here.

What I need from you: a full review of the staging site by everyone who has to approve it, with feedback collected in one place. Compliance sign-off in writing. IT's confirmation that DNS can be changed on the launch date and by whom. A launch date, chosen to avoid anything your team can't afford to have go wrong that week.

Month four: what happens at launch?

Less than you'd think, if the previous three months went to plan.

Launch is a DNS change. The new site has been running on staging for weeks, the content is in, the redirects are tested. On launch day I point your domain at the new site, verify that every redirect resolves, confirm analytics is collecting with consent working, submit the new sitemap to search engines, and watch. Your old site stays available at a private address for a few weeks in case anything was missed.

The first 48 hours are about checking. Search console for crawl errors. Analytics for traffic patterns that look wrong. Forms, by submitting each one and confirming it lands where it should. Your team should be checking too, especially the pages they know best.

Milestone: launch. The final payment is due here.

What I need from you: someone available on launch day who can make the DNS change or has authorized me to, and someone who can answer a question quickly if something unexpected comes up. An announcement plan, if you're making one, timed for a few days after launch rather than the day of.

What is hypercare?

The 60 days after launch, when I'm watching the site closely and fixing anything that surfaces.

No migration is perfect on day one. A redirect gets missed. A form notification goes to the wrong person. An editor finds a field they need that the content model doesn't have. Hypercare is the period where those things get fixed quickly and without a change request. I monitor search traffic against the pre-migration baseline and investigate any drop. I check Core Web Vitals as real traffic comes in. I answer your team's questions as they get comfortable in the Studio.

By the end of 60 days the site is stable, your team is publishing on their own, and search traffic has settled at or above where it was. That's the definition of done for a migration. Ongoing support after that runs under Platform Care, which is described on the services page.

What I need from you: honest reports of anything that isn't working, as soon as your team notices it. Most post-launch problems are easy to fix and annoying to discover late.

Why does this take four months?

Because the parts that take time are the parts that can't be rushed, and most of them are on the client side.

The code for a healthcare marketing site is not the slow part. Content decisions are slow. Compliance review is slow. Vendor integrations are slow. Design review is slow when the people who need to approve it are busy running a healthcare organization. A four-month plan has room for all of that to happen properly, with weekly written updates so you always know what's waiting on whom.

A plan that promises six weeks either skips these steps or pushes them past launch, where they become your problem. I'd rather tell you four months and hit it.