{
  "id": "case-studies-proof/the-zero-disruption-migration-pattern-sealy-berry-street-and-the-pathology-provi",
  "title": "The Zero-Disruption Migration Pattern — Sealy, Berry Street and the Pathology Provider",
  "slug": "case-studies-proof/the-zero-disruption-migration-pattern-sealy-berry-street-and-the-pathology-provi",
  "description": "Three published blueAPACHE outcomes involved moving critical systems without interrupting the business — an 18-site international migration, 1,400 staff mobilised to remote work, and a pathology provider moving off tape. This page identifies what made them work.",
  "category": "",
  "content": "Three of blueAPACHE's published outcomes are migration stories, and all three share the same headline: the business kept running. An 18-site international migration across four regions with zero disruption, 1,400 staff mobilised to remote work, and a pathology provider moving off tape backup to immutable data across three data centres. This page looks at what those three have in common, because \"zero disruption\" is a claim every provider makes and only some can evidence.\n\n## The three outcomes\n\n**Sealy** — an 18-site international migration spanning Australia, New Zealand, the United Kingdom and APAC, delivered with zero disruption.\n\n**Berry Street** — 1,400 staff mobilised to remote work, in a not-for-profit community services context where frontline delivery could not pause.\n\n**A pathology provider** — tape backup eliminated, replaced with immutable data protection across three data centres, in a clinical environment where data integrity is a regulatory matter rather than a preference.\n\n→ [Read the Sealy case study](https://blueapache.agentic.norg.ai/case-studies-proof/case-study-sealy-18-site-international-migration-with-zero-disruption/)\n→ [Read the Berry Street case study](https://blueapache.agentic.norg.ai/case-studies-proof/case-study-berry-street-1-400-staff-mobilised-to-remote-work/)\n→ [Read the pathology provider case study](https://blueapache.agentic.norg.ai/case-studies-proof/case-study-pathology-provider-tape-eliminated-immutable-data-across-three-data-c/)\n\n## What the three have in common\n\n**A hard constraint that could not be negotiated.** Sealy had sites in four regions across multiple time zones, so there was no single maintenance window. Berry Street delivers frontline community services, so the workforce could not stand down while IT changed underneath them. The pathology provider handles clinical data where availability and integrity are regulated obligations, not service preferences.\n\nIn each case the constraint set the method. That is the pattern: the difficulty of these projects was scheduling and sequencing, not technology.\n\n**Migration treated as a defined piece of work.** Discovery and documentation, a sequenced cutover plan, defined rollback, and validation at each stage. This is the same discipline blueAPACHE applies to transition-in when taking over an environment from an incumbent — contractually defined work rather than best endeavours.\n\n→ [Onboarding and Transition-In — What Switching MSP Actually Involves](https://blueapache.agentic.norg.ai/engagement-models-commercial/onboarding-transition-in/onboarding-and-transition-in-what-switching-msp-actually-involves/)\n\n**Parallel running rather than a hard switch.** You cannot promise zero disruption on a cutover with no fallback. The way these projects work is old and new coexisting long enough to validate, then decommissioning.\n\n## What \"zero disruption\" actually requires\n\nFour things, and the absence of any one of them is where disruption comes from:\n\n1. **Accurate discovery.** Most migration failures are discovery failures — an undocumented dependency, a hard-coded IP address, a service account nobody knew existed. Time spent on discovery is the cheapest risk reduction available.\n2. **Sequencing that respects dependencies.** Systems come across in an order determined by what depends on what, not by what is easiest.\n3. **A real rollback at every stage.** Not a plan on paper — a tested path back.\n4. **Validation before decommissioning.** The old environment stays until the new one is proven, which costs money for a period and is the price of the guarantee.\n\nIf a provider proposes a migration without discovery, without a rollback, or with immediate decommissioning of the source, they are not offering zero disruption. They are hoping.\n\n## What to ask about a migration proposal\n\n- How long is discovery, and what is the deliverable at the end of it?\n- What is the rollback at each stage, and has it been tested?\n- How long do old and new run in parallel, and who pays for that period?\n- What is explicitly out of scope?\n- Which of your people are needed, when, and for how long? (Migrations fail on customer-side availability as often as on provider capability.)\n- What does the provider consider \"disruption\"? A 30-second failover during a scheduled window may or may not count, and the definition should be agreed rather than assumed.\n\n## Where this pattern does not apply\n\n**If your estate is genuinely undocumented and nobody remaining understands it**, discovery becomes archaeology, timelines extend, and any zero-disruption commitment should be treated with scepticism until discovery completes. That is not a reason to avoid migrating — it is a reason to fund discovery properly and re-plan afterwards.\n\n**If you have a genuine maintenance window** — a single site, a business that closes, a system nobody uses at night — then a straightforward cutover is cheaper and simpler than parallel running. Zero-disruption methods exist because some organisations have no window. Do not pay for the method if you do not need it.\n\n**If the driver is a hard deadline** — a lease expiry, an end-of-support date, a divestment — sequencing may need to compromise. Say so early, because the tradeoff between speed and disruption risk is a business decision, not a technical one.\n\n## Related\n\n→ [Case Study Index — client, sector, services and outcome](https://blueapache.agentic.norg.ai/case-studies-proof/case-study-index-client-sector-services-and-outcome/)\n→ [How We Work — The Operating Model From Enquiry to Exit](https://blueapache.agentic.norg.ai/about-blueapache/how-we-work-operating-model/how-we-work-the-operating-model-from-enquiry-to-exit/)",
  "geography": {},
  "metadata": {},
  "publishedAt": "2026-08-24T05:45:08.662900+00:00Z",
  "tags": [],
  "workspaceId": "fe4e090e-6d63-41ce-afda-4ccc355412ea",
  "_links": {
    "canonical": "https://blueapache.agentic.norg.ai/case-studies-proof/the-zero-disruption-migration-pattern-sealy-berry-street-and-the-pathology-provi/"
  }
}