Your organisation has decided that its existing server environment is no longer adequate. It may be an office server room that has outgrown its original purpose, a facility with limited resilience, or a hosting arrangement that no longer meets the business’s security, connectivity or audit requirements.
The case for change is clear. The move itself feels riskier.
That concern is reasonable. A data centre migration in Ghana can affect payment platforms, patient records, inventory systems, customer portals, identity services and every team that depends on them. Yet the greatest risk rarely lies in the physical journey between locations. It usually comes from incomplete discovery, unclear responsibilities, untested dependencies and the absence of a credible rollback plan.
The latest Uptime Institute Annual Outage Analysis 2026 reinforces the importance of operational discipline. It reports that failures to follow established procedures remain the leading driver of human-error-related outages, while connectivity and other external dependencies are becoming more prominent in publicly reported incidents. A migration therefore needs more than competent engineers. It needs a controlled business-continuity programme.
If your current environment began as a practical internal solution, first read why an office server room is not a professional data centre. Once the decision to move has been made, the following plan shows how to do it with greater control.
Download the practical migration tools
Use this guide alongside the free Onix 90-Day Data Centre Migration Readiness Checklist and editable Migration Planner. They will help you assign owners, gather evidence, track dependencies and control each go/no-go decision.
Scroll down to download both resources.
Define why the organisation is moving
Do not begin with a moving date. Begin with the outcome the organisation expects.
The business case may involve improving resilience, creating room for growth, strengthening physical security, simplifying audits, gaining access to more connectivity options or making infrastructure costs more predictable. Each desired outcome should become a measurable success criterion.
Assign an executive sponsor who can resolve conflicts and approve risk. Name one migration owner with authority across infrastructure, applications, networks, security, suppliers and business teams. Then document scope, budget, decision rights and the conditions that would make the migration successful. Without that governance, individual tasks can be completed while the overall programme remains exposed.
Inventory systems and map every dependency
An asset list tells you what exists. A dependency map tells you what may fail when it moves.
Record every server, application, database, storage platform, licence, backup process and third-party service in scope. Add IP addresses, DNS records, firewall rules, network routes, authentication services, monitoring tools, batch jobs and user groups. Identify the business owner and technical owner for every critical service.
Hidden dependencies commonly cause cutover problems. A payment application may rely on an excluded identity service; a hospital system may use a fixed IP address; a warehouse platform may depend on an overnight supplier transfer.
Interview application owners rather than relying only on discovery tools. Review logs and network flows. The objective is to understand the service chain, not merely the equipment list.
Classify workloads and agree recovery objectives
Not every workload deserves the same migration method, test effort or cutover window.
The US National Institute of Standards and Technology’s contingency-planning guidance places business-impact analysis at the centre of recovery planning. In practical terms, this means asking what operational, financial, legal or customer impact would follow if a system became unavailable or lost data.
Two measures help convert that discussion into an actionable plan:
- Recovery Time Objective (RTO): the maximum tolerable time a system, service or process can remain unavailable after disruption.
- Recovery Point Objective (RPO): the maximum tolerable period of data that could be lost when the system is recovered.
Agree these objectives with business owners, then group workloads by criticality, complexity, dependencies and regulatory impact. The classification should determine sequencing, backups, replication, testing and rollback timing.
Assess the destination environment
A colocation migration changes where infrastructure operates, but it does not transfer every responsibility to the provider. Due diligence should define what the facility supplies, what the customer retains and how the two sides work together during normal operations and incidents.
Assess:
- the facility’s certification and the exact site, phase or infrastructure covered;
- power and cooling topology, maintenance arrangements and tested resilience;
- carrier neutrality, available networks, route options and cross-connect lead times;
- physical security, visitor controls and emergency access procedures;
- fire detection and suppression;
- monitoring, incident escalation and operational support;
- rack, cage, cabling, delivery and equipment-handling requirements;
- audit rights, evidence, reporting and documentation;
- capacity for future power, space and connectivity requirements;
- disaster-recovery options, contractual responsibilities and service levels.
Certification, provider commitments and customer service-level agreements are related but distinct. Design Documents, Constructed Facility and Operational Sustainability certifications evaluate different scopes. Check the exact award against the current certification register; do not convert it into an assumed uptime percentage or a substitute for the customer’s SLA. Onix explores the distinction further in its article on data-centre SLAs and operational reality.
For regulated financial institutions, due diligence has an additional governance dimension. The Bank of Ghana Cyber and Information Security Directive 2026 requires senior management to understand ICT outsourcing risk and prepare due-diligence reports before appointing service providers. It also addresses third-party contracts, audit rights, business continuity, disaster recovery, migration and exit planning. Selecting a facility does not by itself deliver compliance.
Design the migration in controlled waves
Moving everything together concentrates risk. Start with a lower-risk workload, replica or non-production environment that exercises the same processes as later production waves. Use the result to refine timings, monitoring and escalation procedures.
For every wave, document:
- the source and destination configuration;
- the data-transfer or replication method;
- connectivity, routing, firewall and DNS changes;
- hardware, firmware, licence and support compatibility;
- backup and restoration arrangements;
- the change freeze and configuration baseline;
- the test sequence and expected results;
- the maximum decision time available for rollback.
Install and test circuits and cross-connects early. Uptime Institute’s 2026 analysis notes the growing prominence of fibre and connectivity failures, reinforcing the need to examine external dependencies as well as the destination building.
Rehearse the cutover and prove recovery
A runbook is not ready because it has been approved. It is ready when the team has used it, found its weaknesses and corrected them.
Run a tabletop exercise with technical teams, business owners, suppliers and decision-makers. Complete a test migration where feasible. Restore data, verify its integrity and test application access, monitoring, security controls and user journeys. Record actual timings.
The Bank of Ghana’s 2026 Directive is especially explicit for regulated financial institutions: migration and exit strategies should include tested rollback and fallback procedures, while staging should verify technical, operational and security aspects before production migration. The wider lesson applies to every organisation handling critical services.
Cutover readiness checklist
Before approving the migration window, confirm that:
- the inventory and dependency map are current;
- business owners have approved RTO, RPO and acceptable disruption;
- backups are complete and restoration has been tested;
- destination power, space, cabling and connectivity are ready;
- network routes, firewall rules, DNS and monitoring have been tested;
- acceptance tests and expected results are documented;
- internal teams, the facility and suppliers have confirmed coverage;
- communications, escalation contacts and decision authority are current;
- rollback triggers, steps and available decision time are understood;
- the authorised decision-maker has recorded a go, no-go or reschedule decision.
Turn this guidance into a working project plan. Download the free Onix 90-Day Data Centre Migration Readiness Checklist and the editable Migration Planner to assign owners, record evidence and track each decision gate.
Control the migration window
During cutover, the project needs one command structure and one reliable record of events.
Name the migration lead, technical leads and authorised go/no-go decision-maker. Maintain a time-stamped event log and one controlled channel for operational updates. Record deviations, results, incidents and decisions as they occur.
Avoid changes that bypass the runbook. If a step fails, apply the agreed pause and rollback thresholds. The objective is controlled, understood disruption consistent with approved requirements, not an unrealistic promise of zero downtime.
Validate the service, then close the programme
Equipment receiving power does not prove that the business service works.
Run technical checks and end-to-end application tests. Ask business users to confirm critical journeys such as processing a payment, retrieving a patient record or releasing an order. Validate access controls, logging, monitoring, backups and restoration.
Watch performance through an agreed stabilisation period. Update records and procedures, close temporary access, document lessons and obtain formal acceptance.
Only then is the migration complete.
An indicative 90-day data centre migration plan
A 90-day structure can create useful discipline, but it is not a guaranteed timetable.
| Period | Primary objective | Typical outputs |
|---|---|---|
| Days 1-30 | Discover and assess | Business case, ownership, inventory, dependency map, business-impact analysis, RTO/RPO approval and destination due diligence |
| Days 31-60 | Design and prepare | Migration waves, connectivity, replication, backups, security configuration, runbook, acceptance criteria and rollback plan |
| Days 61-90 | Rehearse and migrate | Tabletop exercise, restoration test, phased cutover, application validation, documentation and stabilisation |
Complex, highly interconnected or regulated environments may require substantially longer. The schedule should follow the evidence, not the other way around.
The Africa Data Centres Association’s 2026 report describes continued infrastructure growth alongside power and local-compute constraints. Capacity alone will not replace careful workload decisions, credible recovery arrangements and operational accountability.
Reduce migration risk before the cutover begins
The safest migration is not the one with the shortest moving window. It is the one that enters that window with accurate discovery, approved recovery objectives, tested dependencies, sequenced workloads and clear authority to stop or roll back.
Onix operates a data-centre facility in Accra, Ghana. Onix Accra #1, Phase 1 holds Uptime Institute Tier IV Certification of Design Documents and Tier IV Certification of Constructed Facility. Onix is a carrier-neutral colocation provider and provides access to multiple networks and internet exchanges.
If your organisation is assessing colocation requirements, facility considerations or connectivity options in Accra, speak with Onix. Start the conversation before you commit to a cutover date.
Primary CTA: Download the 90-Day Migration Checklist
Secondary CTA: Get the Editable Migration Planner
Frequently asked questions about data centre migration
What is a data centre migration plan?
A data centre migration plan documents why systems are moving, which workloads and dependencies are in scope, who owns each decision, how data and connectivity will be transferred, how services will be tested and when the team must pause or roll back. It should also define recovery objectives and evidence required for approval.
How long does a data centre migration take?
There is no universal duration. Ninety days can be a useful framework for a bounded migration, but complex, highly regulated or deeply interconnected estates may take much longer. Timelines should reflect dependency discovery, circuit lead times, testing, governance and acceptable business disruption.
What are RTO and RPO in a migration?
Recovery Time Objective is the maximum tolerable time a service can remain unavailable after disruption. Recovery Point Objective is the maximum tolerable period of data that could be lost when the service is recovered. Both should be approved by business owners and used to shape backups, replication, testing and rollback.
What should be tested before a colocation migration?
Test connectivity, routing, firewall rules, DNS, authentication, backups, restoration, data integrity, monitoring, security controls and end-to-end application journeys. The migration team should also rehearse communications, decision authority and rollback procedures.
Does Tier IV certification guarantee an uptime percentage?
No. Tier certification validates a defined design, constructed facility or operational scope against the relevant Uptime Institute standard. Provider commitments and customer SLAs are separate contractual matters and should be assessed independently.
Planning a data centre migration or reviewing your colocation requirements in Ghana? Speak with Onix before you commit to a cutover date. We can help you assess your infrastructure, connectivity and migration requirements.
