Case 1 · Multi-site industrial organisation
Multi-site managed IT takeover without business interruption
An organisation operating across several sites wanted fewer providers, reliable backups and a single incident procedure. The takeover had to happen without stopping the business.
Context
IT operations were split between several providers, each with its own tools, documentation and habits. The organisation wanted fewer providers, more reliable backups and one shared procedure when an incident occurs.
Constraints
- No business interruption during the takeover.
- Several sites to take over in parallel.
- Service continuity to maintain during the handover from existing providers.
Scope
- Systems and networks across the sites
- Backups and restores
- Service monitoring
- Incident escalation procedure
Out of scope : Application changes and projects unrelated to the takeover were handled separately, outside this scope.
Method followed
Phases and their acceptance criteria.
Each phase ends with a verifiable criterion, agreed with the client before moving on to the next.
Phase 01
Audit and inventory
Listing servers, networks, backups, contracts and access for each site, with their dependencies and owners.
Acceptance criterionThe inventory is reviewed and approved by the client; every item to take over has a named owner.
Phase 02
Cutover plan
Splitting the takeover into batches, choosing maintenance windows, defining acceptance tests and a rollback procedure.
Acceptance criterionEach batch has its window, acceptance tests and a written rollback plan before it starts.
Phase 03
Gradual takeover
Taking over systems and networks batch by batch, standardising monitoring across all sites, documenting backups.
Acceptance criterionA batch is only closed after successful acceptance; test restores are performed and logged.
Phase 04
Operations and shared escalation
Moving to day-to-day operations with a single escalation procedure shared by all sites and a named technical contact.
Acceptance criterionThe escalation matrix is approved and known to the client's teams; documentation is handed over.
Logical architecture
Logical organisation after the takeover
Generic diagram: it does not reflect the client's actual number of sites or architecture.
Points of attention
The risks the method had to cover.
Typical risks in this kind of project, and how the method addresses them.
Undocumented dependencies between sites
The inventory covers flows and dependencies before any cutover; no batch starts on an item that is not inventoried.
Downtime during a cutover
Agreed maintenance windows, per-batch acceptance and a rollback procedure prepared in advance.
Backups assumed but never verified
Backups are documented, then proven with real, logged restores.
Knowledge lost when providers change
An organised handover and centralised documentation, handed to the client and kept up to date.
Results
Centralised operations, identified responsibilities and documented recovery procedures.
Deliverables
- Inventory of assets and dependencies
- Documented backup and restore procedures
- Shared escalation procedure
What we would do again
- Start with the dependency inventory, before any technical choice.
- Use short batches with a written rollback: that is what makes a takeover without downtime possible.
- Prove backups with restores, not with success reports.
This case is presented without names, figures or infrastructure details, in line with our confidentiality commitment. An introduction to the client can be arranged, only with their consent.
Go further
Your situation
A similar context?
Tell us about your environment: we will walk you through the right method, without disclosing anything about other clients.