Case file01
Multi-site technical foundation overhaul
Three locations, three technical legacies, one requirement: business continues while the foundation changes.
- INFRASTRUCTURE
- FRANCE / MONACO / SWITZERLAND
- REFERENCE ON REQUEST
What the client entrusted to us
A services group spread across three locations entrusted us with overhauling its technical foundation. Its growth had come through successive mergers: each site kept its server, its provider, its backups and its habits. Nothing had ever been flattened, because nothing ever broke down at the same time.
The initial request came down to one word: “make it reliable”. The diagnosis showed something else. The main risk was not hardware failure — it was the absence of a shared view. Nobody in the group could describe precisely what was running, where, on what, or who was in charge of it.
We therefore treated the matter as an architecture and governance problem, not a machine replacement.
The starting point
What the diagnosis revealed.
Before any technical proposal, we write down the real state — including what unsettles. This description, validated by the teams, is what makes the rest verifiable.
- 01
Partitioned identities
Three separate directories, three password policies, no shared repository. Staff arrivals and departures were handled site by site, by hand.
- 02
Declared backups, never tested
Backups existed on each site, on local media. No restore had been attempted since commissioning.
- 03
Flat network
On each site, workstations, servers and technical equipment shared the same broadcast domain. One compromised workstation exposed the whole site.
- 04
Documentation held by the outgoing provider
Diagrams, credentials and procedures lived with the historic provider. The group depended on them entirely, without measuring it.
- 05
No up-to-date inventory
The fleet was described by no reliable document, and maintenance contracts partly overlapped without anyone able to prove it.
- 06
No monitoring
An outage was reported by phone call, never by alert. Detection depended on team availability.
Constraints
What could not be compromised.
- 01
Business never stops
All three sites receive the public and process files continuously. No cutover could close a working day.
- 02
Data stays within the perimeter
Client files and regulated documents had to remain hosted under the same rules as before the engagement.
- 03
A way back at every step
Each migration wave had to be independently reversible, depending on neither the next wave nor the whole.
- 04
The group must regain control
Reversibility was part of the specification: documentation, access and procedures had to return to the client, not stay with the integrator.
- 05
Consolidate without rebuying everything
Healthy hardware had to be reused. The budget covered architecture, not fleet renewal.
The AIGYROS answer
What we built.
We started by writing down what existed: an exhaustive inventory of servers, services, flows, access rights and contracts, checked against the field on each of the three sites. Each item received a criticality level — vital, useful, incidental — validated by operations managers.
The target architecture followed: one shared foundation, deployed site by site. A single directory for identities, a consolidated virtualised base for services, a network segmented by usage, an immutable backup replicated off site, and unified monitoring for all three locations.
Cutover ran in successive waves, outside business hours, with a written and tested rollback plan for each step. No wave committed the next before full validation.
The final phase was not technical: operating documentation, restore procedures and skills transfer to the group’s teams, so the foundation would stop depending on us.
Conduct
Four stages, held in this order.
Stated durations are orders of conduct magnitude, never commitments: each engagement is recalibrated on its own ground.
- 01A few weeks, across the three sites
Map
Field survey, inventory of services and contracts, team interviews, criticality matrix.
- Exhaustive inventory of fleet and services
- Flow and dependency mapping
- Criticality matrix validated site by site
- Fragility points identified
- 02Study phase, before any intervention
Design
Target architecture, three-year master plan, backup and continuity plan, cutover schedule.
- Target architecture and master plan
- Network partitioning and access policy
- Backup strategy and continuity plan
- Wave-by-wave cutover scenario
- 03Several waves, outside business hours
Cut over
Service-by-service migration, with a rollback plan per step and functional checks after each wave.
- Migration in successive waves
- Rollback plan for each step
- Functional checks after cutover
- Cutover log kept and handed to the group
- 04Closing phase
Hand over
Operating documentation, restore procedures, team training and monitoring commissioning.
- Operating files per site
- Tested restore procedures
- Skills transfer to in-house teams
- Consolidated monitoring in service
What changes
Before, after — no showcase figures.
We do not publish improvement percentages: they cannot be verified from outside. What can be described, on the other hand, is the daily gesture that changes.
- Initial situationAfter the engagement
Initial situation: Three directories, three policies, hand-managed accounts
After the engagement: One directory, policies deployed per site
Initial situation: Declared backups, never restored
After the engagement: Immutable off-site copy, proven and dated restore
Initial situation: Flat network on each site
After the engagement: Segmentation by usage and by location
Initial situation: Outage reported by phone
After the engagement: Consolidated monitoring, alert before incident
Initial situation: Documentation and access held by the provider
After the engagement: Documentation handed to the group, reversible environment
Initial situation: Each site decided alone
After the engagement: Shared governance, a three-year master plan
Deliverables
What stays in your hands.
An engagement is also judged by what it leaves behind. Every deliverable is written to be read without us.
- 01
Inventory and criticality matrix
The real state of the information system, service by service, with dependencies and fragility points.
- 02
Master plan
The target architecture and its three-year trajectory, split into separately fundable stages.
- 03
Operating files
One file per site: diagrams, access inventory, operating procedures and useful contacts.
- 04
Backup and continuity plan
Backup strategy, off-site copy, continuity scenarios and objectives validated by the group.
- 05
Cutover log
Wave chronology, checks performed, incidents met and resolutions applied.
- 06
Restore procedures
Step-by-step guides, tested, with the recovery times actually observed during drills.
Excluded scope
What the engagement did not include.
A blurry scope costs more than an incomplete one. So we write it down in black and white, from the proposal stage: what is handled, and what is not.
- Workstation fleet renewal, handled in a later phase.
- Premises cabling and physical infrastructure works.
- Replacing business software: it was kept and reintegrated into the new foundation.
- The group’s website overhaul, outside this engagement’s scope.
A successful cutover goes unseen.
Case file
Multi-site technical foundation overhaul
Case 01 — Infrastructure
Area of operation: France / Monaco / Switzerland
Other case files
Prendre contact
Does your situation resemble one of these?
Tell us about your environment, your constraints and what cannot be compromised. We answer with analysis, not a catalogue.