Cloud migration rarely fails because the technology does not work. It fails, or disappoints, because decisions that should have been made before the first workload moved were left until afterwards: which data may go where, who is accountable, how to recover and how to leave. For banks and public-sector bodies, which carry regulatory scrutiny and public trust, these decisions cannot be improvised. The checklist below follows the order in which they are best made.
1. Assess readiness before you move anything
Start with an honest inventory. You cannot secure or migrate what you have not catalogued.
- List applications, owners, dependencies, data types and integration points.
- Identify legacy systems that cannot be moved safely and decide whether to retire, replace, rehost or keep them on premises.
- Assess skills, processes and governance, not only technology. Who will operate the cloud environment, and under which change and incident procedures?
- Check connectivity capacity and resilience between your sites and the provider.
2. Build a secure landing zone first
A landing zone is the pre-built, governed foundation into which workloads are placed. It should exist, and be reviewed, before production migration begins.
- A defined account or subscription structure with separation between production, non-production, networking and security functions.
- Central identity with MFA, least-privilege roles and protected emergency access.
- Network design with segmentation, controlled ingress and egress, and private connectivity to your sites.
- Mandatory logging, monitoring, encryption and key-management standards, enforced through policy-as-code so teams cannot bypass them.
3. Let data classification drive placement
Not every workload belongs in the same place. Classify data first, then decide where each class may live: on premises, in a local or private environment, or in a public cloud region. Consider confidentiality, integrity and availability needs, contractual and sector obligations, and the sensitivity of keys, backups and logs. Legal and regulatory advice should confirm which constraints apply to your institution; do not rely on assumptions. Highly sensitive systems may justify a phased approach, with lower-risk workloads moving first to build experience.
4. Plan disaster recovery and an exit strategy
Migrating to the cloud does not remove the need for continuity planning. It changes it.
- Define recovery time and recovery point objectives for each service, in line with your business impact analysis and ISO 22301 practices.
- Design for failure domains: multiple zones, tested backups held separately from production, and documented failover procedures.
- Run recovery tests and record the results.
- Prepare an exit strategy: data export formats, portability of workloads, contract exit terms, and the time and cost of moving out. Even if you never use it, having it reduces lock-in risk and strengthens your negotiating position.
5. Manage vendor and concentration risk
Treat the cloud provider as a critical supplier. Review certifications and independent audit reports such as ISO/IEC 27001 and SOC 2 reports, but remember that a certificate covers the provider, not your configuration. Examine contract terms on incident notification, audit and inspection rights, subcontractors, data location, support access and termination. Assess concentration risk if many critical services depend on one provider or one region, and reflect the findings in your risk register and board reporting.
How Wethaq ICT helps
Wethaq ICT supports banks and public-sector bodies through cloud readiness assessments, landing zone design, data classification and placement workshops, disaster recovery planning and testing, and vendor risk reviews. We help you move at a pace your governance can support, with security decisions made early rather than repaired later.
Let’s build a secure foundation for your digital future
It starts with a free consultation: we learn your challenges and goals, then propose a service package tailored to your needs and budget.