The problem this solves
Many organisations run important systems on servers that are out of warranty, operating systems that no longer receive patches, and databases maintained by one or two people who know their quirks. Every hardware failure is a scramble, scaling means buying more equipment, and security teams cannot easily see what is running where.
Moving to the cloud promises relief, but migrations that treat every application the same way, or that start with infrastructure before understanding dependencies, frequently stall or overrun. This blueprint shows how Twara Technologies would plan and carry out a legacy migration so that each workload moves by the right route, on a secure foundation, with cutovers that can be rehearsed and reversed. It is a reference approach; any real engagement starts by assessing the client’s actual estate.
Architecture
The target state separates a shared foundation from individual workloads.
[On-premises estate]
servers, VMs, databases, file shares, batch jobs
|
[Discovery + dependency map] --> [Strategy per workload] --> [Migration waves]
| |
[Replication: VM / database CDC / file sync] -------------------->|
v
+------------------------------ Landing zone ------------------------------+
| [Identity: SSO, MFA, roles] [Network: hub-spoke, private links, VPN] |
| [Accounts / subscriptions per environment] [Guardrail policies] |
| [Central logging + SIEM] [Backup + DR] [Cost tags + budgets] |
| |
| [Rehosted VMs] [Managed databases] [Containers] [SaaS replacements] |
+---------------------------------------------------------------------------+
|
[Observability: logs, metrics, traces, alerts] --> [Operations + support]The landing zone is built first and defined as code, so every subsequent workload inherits the same identity, network, logging and policy controls.
Key design decisions
Strategy per workload. AWS’s prescriptive guidance describes seven migration strategies, the “7 Rs”: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The same guidance recommends against refactoring during large migrations, suggesting that teams rehost, relocate or replatform first and modernise afterwards. The blueprint follows that principle: applications are moved with minimal change unless there is a strong reason to modernise in flight, and the strategy matrix records the reason for each choice.
Choice of cloud provider. AWS, Microsoft Azure and Google Cloud all offer mature migration tooling, managed databases and Indian regions. The choice is shaped by existing licences (for example Microsoft workloads), team skills, required managed services and commercial terms. Multi-cloud adds resilience in theory but also complexity; the blueprint recommends one primary provider unless there is a specific need.
Database migration approach. Offline dump-and-restore is simple but requires downtime proportional to data size. Continuous replication with change data capture (using services such as AWS DMS or Azure Database Migration Service, or tools such as Debezium) keeps the target in sync until a short final cutover. Engine changes, such as from a commercial database to PostgreSQL, bring licence savings but add conversion and testing effort.
Infrastructure as code. Terraform, or provider-native tools such as AWS CloudFormation and Azure Bicep, make environments reproducible and reviewable. The blueprint treats manual console changes as exceptions to be recorded and folded back into code.
Hybrid period. Most migrations run in a hybrid state for some time. Secure connectivity (site-to-site VPN or dedicated links), DNS strategy and identity federation are designed for that period, not as afterthoughts.
Security and compliance
A migration is an opportunity to raise the security baseline: centralised identity with multi-factor authentication, encryption by default, segmented networks and complete logging. For organisations in India, CERT-In’s Directions of 28 April 2022 are directly relevant to cloud design. They require covered entities to synchronise ICT system clocks with NTP servers of NIC or NPL (or sources traceable to them), report listed cyber incidents to CERT-In within six hours of noticing them, and keep logs of all ICT systems securely for a rolling 180 days within Indian jurisdiction. The landing zone’s time configuration, central log storage and region choice are set with those requirements in mind.
Where migrated systems hold personal data, Rule 6 of the DPDP Rules, 2025, made under India’s Digital Personal Data Protection Act, 2023, sets minimum safeguards that include encryption or masking, access control, access logs, backups and retention of those logs for one year unless another law requires otherwise. Sector regulators may add their own requirements on outsourcing and data location; the blueprint records these during assessment and confirms them with the client’s compliance team.
Phased rollout
- Assess. Discover the estate, map dependencies, capture compliance constraints and build the strategy matrix and business case.
- Foundation. Build the landing zone as code, connect identity and networks, and set up logging, backup and cost controls.
- Pilot wave. Migrate a small number of lower-risk applications end to end, refining runbooks, testing and cutover procedures.
- Migration waves. Move remaining workloads in dependency-aware groups, each with rehearsed cutover and rollback plans.
- Optimise and modernise. Rightsize resources, decommission old infrastructure, and modernise selected applications now running in the cloud.
- Operate. Ongoing monitoring, patching, cost reviews and incident response under a managed support arrangement.
Risks and how the design handles them
| Risk | How the design responds |
|---|---|
| Hidden dependencies break during cutover | Tool-based discovery plus interviews, dependency-aware waves and rehearsed cutovers |
| Extended downtime during data migration | Continuous replication with a short final switch, and rollback criteria agreed in advance |
| Cloud costs exceed expectations | Tagging, budgets and rightsizing from the first wave, with regular cost reviews |
| Security gaps from rushed configuration | Guardrails and baseline controls enforced in the landing zone, defined as code |
| Undocumented legacy behaviour | Parallel running and reconciliation for critical processes before decommissioning |
| Skills gap in the operating team | Runbooks, knowledge transfer and an optional managed operations phase |