What does the migration itself look like?

# What does the migration itself look like?

Five phases over about four months: two weeks to prepare, four to settle the content model and the design system, seven to build and migrate, one to launch, then sixty days of hypercare. Three payments, at signature, at staging sign-off, and at launch. On my side it's one engineer plus a designer; on yours it's one decision-maker, one content owner, a clinical reviewer, whoever signs off for compliance, and someone in IT. The code is the predictable part. The schedule is set by the three things clients underestimate every time: content, approvals, and access.

I wrote the month-by-month version of this in What a four-month healthcare site migration actually looks like. This chapter is the other half: who does what, which decisions are yours and when they're due, and what you're supplying.

What are the phases, and how long is each?

Fourteen weeks to launch, then sixty days of hypercare, with a named exit criterion for each phase so nobody has to argue about whether it's done.

• Prepare (weeks 1 to 2). Access granted per the checklist, accounts moved into your organization's name, content freeze rules agreed, staging environment up. Exit: kickoff complete. First payment, 40 percent, on signature.
• Model and design system (weeks 3 to 6). Content model finalized (chapter 3), Studio configured, design implemented as components. Exit: your team has used the Studio on staging and signed off the model.
• Build and migrate (weeks 7 to 13). Templates, content migration, integrations, redirect map (chapter 4), forms and consent (chapter 5), accessibility and performance passes. Exit: content QA complete and staging sign-off. Second payment, 40 percent.
• Launch (week 14). Redirect tests, DNS, analytics and consent verified, launch checklist signed. Exit: site live. Final payment, 20 percent. Chapter 9 covers the week itself.
• Hypercare (60 days). Fixes without change requests, two training sessions, written guide, search traffic watched against the pre-migration baseline. Exit: day 60, with a Platform Care proposal if you want ongoing support.

The assessment sits in front of all of this and produces the inventory (chapter 2) and the fixed price; its fee is credited against the build. Sites with fewer than fifty pages and no integrations run shorter. Sites with several hundred pages, a directory, and five integrations run to five months. Four is the middle.

Who does what?

Two people on my side, six roles on yours, and the six can be fewer people as long as each role has a name.

On my side: me, for everything technical from the content model to the redirects to the training, and a designer, either yours or one I've shipped with before, working from the content model so the design and the structure match.

On yours:

• Decision-maker. One person who can say yes. Committees review; one person decides. If nobody fits that description, the timeline is fiction.
• Content owner. Owns the keep, rewrite, or retire call on every page and the schedule for the rewrites. The biggest job on your side, and the one most often left unassigned.
• Clinical reviewer. A clinician who confirms condition and service content is still accurate and whose name goes in the reviewedBy field. Usually a part-time role; needs to know in month one that the pages are coming.
• Compliance or legal. Reviews the forms, the analytics plan, and the legal pages, and signs off in writing. Named at kickoff so their review time is in the plan, not a surprise in month four.
• IT. DNS, certificates, single sign-on if the Studio uses it, and any firewall or email rules the forms touch. Confirms in month three that DNS can be changed on the launch date and by whom.
• Vendor contacts. A name at each system being integrated (scheduling, CRM, careers, email), and someone on your side willing to chase them.

Which decisions are yours, and when are they due?

About ten, each with a week attached, and each with a turnaround written into the statement of work.

• Week 1: who fills each role above; what the launch window can't collide with.
• Week 2: which old pages are retired rather than migrated (the inventory's kill column).
• Weeks 3 to 4: content model sign-off, section by section.
• Weeks 4 to 6: design direction, then page designs, reviewed within a few days of delivery.
• Weeks 6 to 8: compliance sign-off on the forms and analytics plan, in writing.
• Weeks 7 to 12: the content edits themselves, on the schedule the content owner set in week 2.
• Week 13: staging sign-off from everyone who has to approve, feedback in one place.
• Week 13: launch date and go or no-go.
• Launch day: the DNS change, or written authorization for me to make it.
• Hypercare: anything that isn't working, reported the day your team notices.

The turnaround that goes in the SOW is a week for each. A decision that takes three weeks moves the date by two; nothing else on the plan can absorb it, because everything after it depends on it. I'd rather write that down at the start than discover it in month three.

What are you supplying?

Content, approvals, and access, plus a few things that are easy to forget.

• Content. The rewrites, the updated bios, the clinical review. On a 150-page site, expect roughly forty pages to need a real editorial pass. The migration script moves everything; it doesn't make it good.
• Approvals. Design reviews in days, not weeks. Compliance sign-off in month two, not month four. Staging sign-off from every approver at once, not one at a time.
• Access. Everything on the chapter 2 access checklist: registrar, DNS, host, CMS, analytics, Search Console, tag manager, each integration. Accounts registered to former employees transferred before the build depends on them.
• Brand assets. Guidelines, logos, fonts and their licences, photography and its usage rights.
• A launch-day person. Someone reachable for the few hours around the DNS change.
• An announcement plan, if there is one, timed a few days after launch rather than the morning of.

Why do content, approvals, and access get underestimated?

Because each one looks like a small task from the outside and is a queue of other people's time from the inside.

Content looks like updating a few pages. It's forty pages, four authors, one clinician, and a schedule nobody wrote down. The fix is a named owner with the authority to decide and the time to do it, and a page count agreed in week two.

Approvals look like "legal will take a look." It's a review of every form, every script, and every legal page, by people who have a hospital to run. The fix is naming them at kickoff and putting the forms and analytics plan in front of them in month two, when a no is cheap.

Access looks like sending over a login. It's a registrar account in the name of an agency that closed, a Search Console property owned by a marketing contractor from 2021, and a scheduling tool whose admin left. The fix is the checklist in week one and the rule that every account ends up in your organization's name before launch, whatever it takes to get there.

None of these is a technical problem, and no amount of engineering speed fixes them. That's why a plan that promises six weeks either skips them or pushes them past launch, where they become yours.

What does the weekly update look like?

A short written note, the same day every week, with four headings: done, next, waiting on, and date impact.

"Waiting on" is the important one. It names the decision or the deliverable and the person, and "date impact" says what it costs if it doesn't arrive this week. There's a call if something needs discussing; otherwise the note is the meeting. Decisions get logged with a date, so when someone asks in month four why a page was retired, the answer is in the log from week two.

What changes the timeline?

Five things, and four of them are on the client side.

Late content is the usual one. Vendor integrations are second: a scheduling vendor's API team on a six-week backlog is not something either of us controls, so integrations start in month two and get flagged in the update the week they stall. Design review loops are third. Scope additions are fourth; the price is fixed, so anything not in the inventory is a change order with a cost and a date impact, which is the point of the inventory. The fifth is a launch week that collides with something on your side, a board meeting or an audit or a conference, which is why the launch window is a week-one question.

What doesn't change the timeline: the build itself. With the starter, the content model and the components are days of work, not weeks. The four months is a plan for the human parts to happen properly.

Checklist

Before launch - [ ] Staging reviewed by every approver, feedback in one place, signed off - [ ] IT has confirmed who changes DNS and when - [ ] Redirect map read and confirmed by the content owner - [ ] Launch-day contact and hypercare reporting path agreed Companion code in the Healthcare Sanity Starter: docs/MIGRATION.md (the launch checklist by phase). The month-by-month narrative is in the four-month migration post; the assessment that produces the plan is described at /assessment.