The short answer
Treat a migration as small, reversible moves: list every application and dependency, choose a path for each, confirm where data lives and who secures it, estimate running costs, then migrate in waves with a tested rollback. Bad migrations usually skip the inventory or the rollback, not the technology. This applies to AWS, Microsoft Azure or Google Cloud, from a server room or a hosting provider.
1. Know what you have
You cannot migrate what you have not found. Inventory:
- Every server, application and database, even ones "only accounting uses"
- Dependencies: databases, file shares, licence servers
- Outside integrations: banks, suppliers, payroll, e-commerce
- Scheduled jobs, scripts and overnight reports
- Business and technical owner of each system
- Licensing terms that restrict cloud use, and US-dollar pricing
2. Decide the path for each application
AWS describes seven migration strategies, the 7 Rs; the thinking applies on any cloud.
| Strategy | In plain terms |
|---|---|
| Retire | Switch it off |
| Retain | Leave it where it is for now |
| Rehost | Move it as it is ("lift and shift") |
| Relocate | Move a whole platform, such as virtual machines, to its cloud equivalent |
| Repurchase | Replace it with a software-as-a-service product |
| Replatform | Move it with some changes, such as a managed database |
| Refactor | Redesign it to use cloud services fully |
When each strategy fits
- Retire: nobody uses it, or another system already does the job.
- Retain: it depends on local hardware, was just upgraded, or is not ready.
- Rehost: you need to exit a data centre quickly and optimise later.
- Relocate: you run a virtualisation platform with a cloud-hosted version.
- Repurchase: a good SaaS product now does what the old system did.
- Replatform: a few changes bring real savings or less maintenance.
- Refactor: the application limits the business and is worth rebuilding.
AWS calls refactoring during a large migration the most complex option and generally recommends moving first, modernising after. We agree for most organisations (modernising legacy applications covers what comes next).
3. Settle data location and privacy
There is no major public cloud region inside Nigeria, so choose deliberately between a local data centre (in Lagos or Abuja, for example) and a region abroad: AWS lists its current regions, and the nearest large ones on the major platforms are in South Africa and Europe. Check which services, backups and disaster recovery copies stay where you chose; whether support, monitoring, email delivery or other add-ons process data elsewhere; and data-location terms from customers, funders or regulators, including sector rules (the Central Bank of Nigeria for financial institutions, NITDA guidance for public institutions).
The NDPA. The Nigeria Data Protection Act 2023, enforced by the Nigeria Data Protection Commission, sets rules for transfers outside Nigeria, and you remain accountable for personal data a cloud provider processes for you. Confirm the transfer basis and contract terms with your legal adviser and the NDPC. This is general information, not legal advice.
4. Agree who secures what
Cloud security is a shared responsibility: the provider secures the infrastructure; you keep identities, data, configuration and, depending on the service, operating systems and applications. Your accountability for the risks does not move to the provider. Before the first move, set up:
- Single sign-on with MFA
- Least-privilege admin roles
- Separate production and test environments
- Central logging
- Alerts on suspicious activity
5. Estimate and control cost
Costs once hidden in a server purchase become monthly charges, mostly in US dollars. Estimate storage, compute, data transfer, backup and licensing in naira (or US dollars where a licence or service is priced in dollars), compare with today's spend including hardware refreshes, power backup and support, allow for exchange-rate movement, and set budget alerts and tagging from day one. See AWS cost optimization for habits that keep spending in check.
Rather talk it through? We can build your inventory, recommend a path for each application and plan the waves, with rollback at every step. Talk to a Promatics specialist
6. Plan waves, testing and cutover
- WavesLower-risk systems first, to build confidence.
- Success criteriaWhat must work, for whom, and how you will check.
- Real-location testsFrom where people work, over their links, including slow or dropped connections.
- Cutover windowAgreed with the business, with a change freeze.
- Rehearsed rollbackIf you cannot go back, you are not ready to go forward.
- Test restoreBackups confirmed in the new environment.
Systems hosted abroad depend on your connection: plan redundant links (fibre plus a second provider or 4G/5G failover). For backups, see backup and disaster recovery.
7. After the move
Migration day starts operations. Decommission old servers securely, update documentation and runbooks, review costs after the first full month, and schedule a rightsizing and modernisation review. On-site network equipment and links that reach your cloud services still need UPS, inverter, solar or generator cover.
What usually goes wrong
The forgotten dependency
A report or integration that read from the old server breaks.
Lift and shift, then shock
Servers sized for on-premises peak run all month at full cloud cost, in dollars.
Security "later"
Default settings and shared admin accounts become permanent.
No rollback
A problem appears after cutover, with no clean way back.
The checklist
- Inventory of applications, databases, integrations and scheduled jobs complete.
- Business and technical owner named for each system.
- Migration path (retire, retain, rehost, relocate, repurchase, replatform, refactor) chosen per application.
- Licensing checked for cloud use.
- Region chosen and data location of backups and add-on services confirmed.
- NDPA obligations, transfer rules, sector rules and contracts reviewed.
- Identity, MFA, admin roles and logging in place before the first move.
- Naira or dollar cost estimate, exchange-rate allowance, budget alerts, tagging.
- Redundant internet links for offices that depend on the new environment.
- Waves, success criteria and cutover windows agreed with the business.
- Rollback plan written and rehearsed.
- Backups configured and a restore tested in the new environment.
- Old systems decommissioned and documentation updated.
When to bring in help
An internal team can often move one simple, self-contained application with no personal information using the provider's documentation. Bring in help for interdependent systems, personal or regulated data, rollbacks nobody can rehearse, or an environment nobody will own afterwards. Our cloud services and migration team plans and runs migrations and can manage the environment afterwards.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- About the migration strategies, AWS Prescriptive Guidance
- AWS Regions, Amazon Web Services documentation
- Shared Responsibility Model, Amazon Web Services
- Nigeria Data Protection Commission (NDPA, GAID 2025, rules on transfers outside Nigeria), Nigeria Data Protection Commission
- National Information Technology Development Agency (Nigeria Cloud Computing Policy and guidelines), NITDA
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.