Services / Flagship

Cloud migration and modernisation, with a way back at every gate

We move estates between clouds and out of data centres: 7 Rs disposition assessment, wave planning with rehearsed rollback gates, DMS and change-data-capture data movement, and a cost baseline validated against real bills after cutover. Azure-to-AWS is our most requested programme, and we publish the full service mapping and a complete worked proposal rather than keeping it behind a sales process.

Every workload gets a disposition before anything gets scoped
No wave proceeds until its rollback has been executed successfully once
Cost baseline signed off before the first workload moves
Licence position reviewed in assessment, not discovered at invoice

Request the Azure-to-AWS proposal Cloud & DevOps engineering

At a glance

Framework: 7 Rs disposition per workload
Assessment duration: 3 – 5 weeks, fixed fee
Typical programme: 4 – 8 months for a 40-workload estate
Most requested route: Azure to AWS
Data movement: AWS DMS, native replication, CDC, dual-write
Cutover windows: Minutes for most workloads; near-zero for stateless
Retirable workloads found: Typically 10 – 20 percent of the estate
Enquiries: nitesh@redcubical.com

Framework

What are the 7 Rs of cloud migration?

Every workload gets exactly one disposition, agreed in writing, before it enters a wave. Two of the seven remove work from the programme entirely.

The 7 Rs, defined

The 7 Rs are Retire, Retain, Rehost, Relocate, Replatform, Refactor and Repurchase. Assessment assigns one to each workload based on business value, technical debt, licence position and change appetite. Getting the disposition right is the single highest-leverage decision in a migration, because refactoring something that should have been retired is pure waste.

7 Rs disposition table
Disposition	What it means	Choose when	Effort	Typical share of estate
Retire	Decommission the workload. Archive its data and switch it off.	No active users, superseded by another system, or the only consumer is a report nobody reads	Very low. Data archive and stakeholder sign-off	10 – 20 percent
Retain	Leave it where it is, for now, with a documented review date.	Hardware dependency, an unresolvable licence constraint, a vendor contract that has not expired, or a decommission already scheduled	None beyond documenting the decision	5 – 15 percent
Rehost	Lift and shift to equivalent cloud compute with no code change.	A deadline is fixed, the application is stable, and modernisation can follow later	Low. Image conversion, network mapping, testing	25 – 40 percent
Relocate	Move the hosting container wholesale without changing the workload.	VMware estates moving to VMware Cloud on AWS, or a hypervisor-level move to keep the operating model identical	Low, but requires the specific target platform	0 – 10 percent
Replatform	Change what it runs on, keep the application substantially the same.	Self-managed database to RDS or Aurora, IIS to ECS Fargate, self-hosted queue to SQS	Medium. Configuration and connection changes, real testing	20 – 35 percent
Refactor	Re-architect. Decompose, adopt managed services, rewrite components.	The current architecture is the actual constraint on the business, and the workload is strategic enough to justify the spend	High. Effectively a development programme	5 – 15 percent
Repurchase	Replace with a SaaS product and migrate the data across.	The workload is a commodity — CRM, HR, ticketing, expenses — that no longer differentiates you	Medium. Dominated by data migration and change management	5 – 15 percent

Shares are from our own assessments and will vary with estate age. The pattern that holds is this: clients consistently expect more refactoring than the evidence supports, and consistently underestimate how much is retirable. Both errors are expensive in opposite directions.

Phase 1

Assessment: what you get in three to five weeks

Fixed fee, fixed deliverables. Written so another vendor could execute against it, which is the only honest test of whether an assessment is real.

Assessment deliverables

Assessment produces a workload inventory with dependencies, a 7R disposition per workload with justification, a target architecture, a wave plan with rollback gates, a licence position review, a cost baseline for current and target state, and a risk register with named owners. You own all of it regardless of who executes the migration.

Deliverable 1

Workload inventory and dependency map

Discovery agents plus network flow analysis plus interviews, because none of the three alone is complete. Agents miss what is switched off. Flow logs miss batch jobs that ran last month. Interviews miss what nobody remembers.

Every workload with owner, criticality and user count
Inbound and outbound dependencies including scheduled jobs
Observed utilisation over at least 14 days, not provisioned size
Data volumes, growth rate and retention obligations
Integration surfaces, including partner and third-party endpoints

Deliverable 2

7R disposition register

One disposition per workload with the reasoning recorded, plus the alternatives rejected. This is the document that gets argued over, and that argument is the point.

Disposition and justification per workload
Business owner sign-off on every Retire decision
Review date on every Retain decision
Effort and risk rating feeding the wave plan

Deliverable 3

Target architecture and landing zone design

Account structure, network topology, identity model, guardrails and tagging standard. Built before any workload moves so nothing lands in an ungoverned account.

Multi-account organisation with service control policies
VPC and connectivity design including Direct Connect or VPN
Identity model and permission boundaries
Encryption, key management and logging baseline
Tagging standard enforced by policy-as-code

Deliverable 4

Wave plan with rollback gates

Workloads grouped into waves that can move and be validated together. Dependencies respected so a wave never leaves a chatty pair split across two clouds paying egress in both directions.

Wave composition with dependency rationale
Entry and exit criteria per wave
Rollback trigger, procedure and named decision owner
Cutover window and required freeze periods
Dress-rehearsal schedule preceding each wave

Deliverable 5

Licence position review

The deliverable clients most often skip and most often regret skipping. Windows Server, SQL Server, Oracle, third-party middleware and anything with per-core or per-socket terms.

Per-product mobility and portability position
Software Assurance status and what it does and does not permit
Licence-included versus bring-your-own cost comparison
Flagged items requiring vendor confirmation before cost sign-off

Deliverable 6

Cost baseline and risk register

Current-state spend normalised, target-state modelled at three rightsizing levels, and the migration programme cost itself, including the period where you pay for both environments.

Twelve-month current-state baseline from real billing data
Target model: like-for-like, rightsized, and rightsized plus committed
Dual-running cost during the migration window
Data transfer and egress modelled explicitly
Risk register with likelihood, impact, owner and mitigation

Azure to AWS

Azure to AWS service equivalence

The mapping we work from. Equivalence is never exact, and the third column is the part that determines your effort estimate.

How Azure services map to AWS

Most Azure services have a workable AWS counterpart, but the mapping is rarely one to one. Compute and storage translate cleanly. Identity, messaging semantics and managed data services carry behavioural differences that require code or configuration change. The table below is our working mapping, with the gap that actually costs effort named in each row.

Azure to AWS service mapping with migration notes
Azure service	AWS equivalent	What differs, and where the effort goes
App Service	Elastic Beanstalk or ECS Fargate	Beanstalk is the closest managed analogue; ECS Fargate is where we land most of them. Deployment slots have no direct equivalent, so blue-green is rebuilt with target groups or CodeDeploy. Built-in authentication in App Service must be reimplemented, usually with Cognito or an ALB OIDC action.
Azure Kubernetes Service (AKS)	Amazon EKS	Manifests port largely unchanged. The work is in the platform layer: CNI and IP address planning, IAM Roles for Service Accounts replacing workload identity, Azure Disk and Files storage classes becoming EBS and EFS CSI drivers, and ingress moving from Application Gateway Ingress Controller to AWS Load Balancer Controller.
Azure Functions	AWS Lambda	Programming models differ. Bindings and triggers have no equivalent and become explicit SDK calls. Durable Functions orchestration maps to Step Functions, which is a redesign rather than a port. Cold start and timeout characteristics differ enough to require load re-testing.
Azure SQL Database / Managed Instance	Amazon RDS for SQL Server, or Aurora PostgreSQL with conversion	RDS for SQL Server is the low-risk path but check feature parity, particularly around cross-database queries, SQL Agent jobs and CLR. Aurora PostgreSQL cuts licence cost substantially but requires schema and code conversion via the AWS Schema Conversion Tool plus real regression testing on stored procedure logic.
Cosmos DB	Amazon DynamoDB (or DocumentDB for the Mongo API)	Not a drop-in swap. Partition key design, consistency models and the absence of a direct SQL-like query surface mean the data access layer is rewritten. Cosmos multi-region write maps to DynamoDB global tables with different conflict semantics. Change feed maps to DynamoDB Streams.
Blob Storage	Amazon S3	The cleanest mapping in the whole table. SAS tokens become presigned URLs, access tiers map to S3 storage classes, lifecycle rules translate directly. Watch for code depending on Azure-specific metadata headers or blob lease semantics.
Azure Files	Amazon EFS, or FSx for Windows File Server	Choose by protocol. SMB workloads with Active Directory integration go to FSx for Windows File Server. NFS and Linux workloads go to EFS. Getting this wrong is a re-migration, not a reconfiguration, so it is decided in assessment.
Microsoft Entra ID	IAM Identity Center (with Entra ID often retained as identity provider)	Most clients keep Entra ID as the identity provider and federate into IAM Identity Center rather than replacing it. Application-level Entra ID authentication becomes Cognito or a direct OIDC integration. Managed identities map to IAM roles, which is a code change wherever the Azure identity SDK is used.
Service Bus	Amazon SQS, SNS or EventBridge	Service Bus does several jobs that AWS splits across three services. Queues map to SQS, topics and subscriptions to SNS or EventBridge, and content-based routing to EventBridge rules. Sessions, scheduled delivery and dead-lettering behave differently, and FIFO ordering guarantees need explicit design with SQS FIFO.
Event Hubs	Amazon Kinesis Data Streams, or Amazon MSK	If your producers and consumers already use the Kafka-compatible endpoint, MSK is the lower-change path. Otherwise Kinesis is cheaper to operate. Partition and shard models differ, as does retention pricing, so throughput planning is redone rather than translated.
Data Factory	AWS Glue, Step Functions, or MWAA	No single equivalent. Glue covers extract, transform and load with a data catalogue; Step Functions covers orchestration; Managed Workflows for Apache Airflow suits complex dependency graphs. Data Factory pipelines are redesigned, not converted, and this is frequently the largest single line item in an Azure-to-AWS estimate.
Synapse Analytics	Amazon Redshift (with Athena and Glue for the lake side)	Dedicated SQL pools map to Redshift; serverless SQL pools map to Athena over S3; Spark pools map to EMR or Glue. T-SQL to Redshift SQL conversion is real work, particularly around window functions, temporary table patterns and stored procedures.
Azure Monitor and Log Analytics	Amazon CloudWatch (often with Grafana or Datadog)	CloudWatch Logs Insights is less expressive than KQL, and teams fluent in Kusto feel the loss. Every dashboard and alert rule is rebuilt. We usually take the opportunity to instrument with OpenTelemetry so the next platform decision is not another rebuild.
Azure Front Door	Amazon CloudFront (with AWS WAF and Global Accelerator)	CDN and routing map cleanly. WAF rule sets must be re-authored — managed rule groups differ in naming and behaviour — and the rules need to run in count mode against real traffic before enforcement, or you will block legitimate users at cutover.
ExpressRoute	AWS Direct Connect	Same concept, different provisioning lead time. Allow four to twelve weeks for a new cross-connect depending on location and partner. This is the single most common cause of a migration timeline slipping, and it must be started during assessment rather than before the first wave.
Key Vault	AWS KMS plus Secrets Manager (or Parameter Store)	Key Vault covers keys, secrets and certificates in one service; AWS splits them. Keys go to KMS, secrets to Secrets Manager or Parameter Store, certificates to ACM. Every application that reads configuration from Key Vault needs a code change, and automatic secret rotation is configured differently.
Azure OpenAI Service	Amazon Bedrock	Different model catalogues. If you depend on a specific GPT version, verify availability on Bedrock or plan to change model and re-run your evaluation suite. Quota models differ: Azure allocates tokens per minute per deployment, Bedrock applies per-model requests and tokens per minute with a daily ceiling. Prompts almost always need re-tuning across model families.
Azure Machine Learning	Amazon SageMaker	Concepts align — workspaces, experiments, registries, endpoints — but the SDK surface differs enough that pipelines are rewritten. Trained model artefacts port; the training and deployment orchestration around them does not.
Azure Container Registry	Amazon ECR	Straightforward. Images are re-pushed or replicated, geo-replication maps to ECR cross-region replication, and vulnerability scanning maps to ECR enhanced scanning. Remember to update every image reference in manifests, pipelines and Helm values.
Azure DevOps	AWS CodePipeline, or GitHub Actions	We migrate most clients to GitHub Actions rather than CodePipeline: better ecosystem, easier local reasoning, and it keeps CI portable if the cloud choice changes again. Azure Repos to CodeCommit is not recommended given CodeCommit's limited feature set. Pipeline YAML is rewritten, not converted.

Two structural differences run across the whole table. First, Azure resource groups have no AWS equivalent, so grouping and lifecycle management move to tags plus multi-account structure. Second, Azure's role-based access control and AWS IAM differ in evaluation logic — IAM's explicit-deny precedence and resource-based policies mean permission models are redesigned, not translated.

Mechanics

How the data actually moves

Data movement sets the cutover window and therefore the shape of the whole programme. Applications are the easy part.

Data migration mechanisms

Four mechanisms, chosen per data store: AWS DMS for heterogeneous replication with change data capture, native engine replication where source and target are the same engine, CDC streaming via Debezium into Kinesis or MSK for event-driven targets, and dual-write only where the application must be authoritative in both places simultaneously. Dual-write is the last resort, because it moves consistency responsibility into application code.

Data migration mechanism selection
Mechanism	Use for	Cutover window	Main risk
AWS DMS full load plus CDC	Heterogeneous moves such as Azure SQL to Aurora PostgreSQL, or any case needing continuous sync during a long validation period	Minutes. Stop writes, let replication drain, verify lag is zero, switch	Unsupported data types and LOB handling; DMS silently truncates in some configurations if not explicitly set up for full LOB mode
Native engine replication	Same-engine moves: SQL Server Always On or log shipping, PostgreSQL logical replication, MySQL binlog replication	Minutes to seconds. Promote the replica	Version compatibility between source and target, and permissions the managed target may not grant
CDC streaming with Debezium	Feeding an event-driven or lakehouse target, or where multiple consumers need the change stream rather than just one target database	Depends on consumer catch-up rather than the database	Schema evolution handling and exactly-once semantics at the consumer
Dual-write from the application	Cases where both stores must be authoritative during a long transition, or where no replication path exists between source and target	Effectively none, but consistency is now your code's responsibility	Partial failure. One write succeeds and one fails, and reconciliation is now a permanent operational job
Bulk transfer with AWS Snowball or offline media	Multi-terabyte or petabyte datasets where network transfer would exceed the available window	Not applicable — used for the initial seed, then CDC catches up	Physical logistics and the delta accumulated while the device is in transit
Backup and restore	Non-critical workloads that tolerate a maintenance window	Hours	Longest window of any option; only acceptable where the business genuinely agrees to the outage

Every mechanism is paired with reconciliation: row counts, checksums on key columns, and business-level totals such as ledger balances or open order values. Row counts alone have passed while values were silently wrong on estates we have inherited.

Execution

Wave planning, cutover and rollback

How waves are composed

Dependency-complete groups. Chatty components move together. Splitting a pair across two clouds means latency on every call and egress charges in both directions.
Wave zero is a real workload. Low criticality, low volume, genuine production traffic. Not a hello-world deployment. It proves the landing zone, the pipeline, the monitoring and the runbook.
Escalating criticality. Each wave is slightly harder than the last, so the team's confidence and the runbook's accuracy grow together.
Databases lead their applications. Replication is established and validated well before the application wave moves.
Explicit entry and exit criteria. Written before the wave starts. Exit criteria include error rate, latency, reconciliation status and business sign-off.
One dress rehearsal minimum. Full runbook executed against a production-shaped environment, timed, with the rollback also executed.

The cutover runbook

T-14 days. Reduce DNS TTLs to 60 seconds. This has to happen early enough for resolver caches to expire, and forgetting it is the classic cutover failure.
T-7 days. Dress rehearsal complete, rollback executed successfully, timings recorded, go or no-go criteria confirmed.
T-2 days. Freeze changes in both environments. Confirm replication lag is stable. Verify target capacity, WAF rules in count mode, and certificate validity.
T-0 minus 60 minutes. Go or no-go call with the named decision owner. Comms sent. Bridge opened.
T-0. Stop writes at source. Confirm replication lag reaches zero. Run reconciliation. Switch traffic. Enable writes at target.
T-0 plus 30 minutes. Smoke tests, synthetic journeys, error rate and latency compared to the pre-cutover baseline, not to an abstract target.
T-0 plus 4 hours. First formal checkpoint. Business validation on real transactions completed by the business, not by us.
T-0 plus 48 hours. Wave acceptance decision. Until this point the source stays warm and rollback remains available.
T-0 plus 14 days. Source decommission scheduled, not executed. Data archived first, with restore tested.

Commercials

Cost baseline and post-migration validation

How we handle migration economics

We build a twelve-month normalised baseline from your actual billing data, then model three target states: like-for-like, rightsized against observed utilisation, and rightsized plus committed through savings plans. Ninety days after each wave we reconcile the real bill against the model and publish the variance, including where we were wrong.

Cost modelling components
Component	What it captures	Frequently missed
Current-state baseline	Twelve months of real spend, normalised for one-offs and seasonality	Reserved instance and enterprise agreement discounts that do not transfer to the new provider
Target like-for-like	Same shapes on the new cloud, no optimisation	Often slightly higher than source. Publishing this honestly avoids a nasty conversation at month one
Target rightsized	Instance families and sizes matched to observed p95 utilisation over 14 days or more	Peak-driven workloads where p95 sizing causes throttling at genuine peak
Target rightsized plus committed	Savings plans and reserved capacity on the proven baseline only	Committing before the architecture settles. We wait 60 days post-wave before any commitment
Data transfer and egress	Cross-region, cross-zone, internet egress and NAT gateway processing	Almost always underestimated. Cross-zone chatter between components split across zones is invisible until the bill arrives
Licence delta	Windows, SQL Server, Oracle and middleware cost differences	Azure Hybrid Benefit not applying on AWS. This single item has moved projected savings into projected increases
Dual-running cost	The period where both environments are live	Extending because a wave slipped. Budget for four to eight weeks longer than the plan implies
Programme cost	Our fees, internal team time, third-party tooling, Direct Connect and circuit charges	Internal staff time, which is a real cost even when it does not appear on an invoice

Payback on a well-executed migration with rightsizing is typically 14 to 26 months. Anyone quoting a six-month payback on a lift-and-shift is either ignoring the programme cost or assuming savings that require modernisation they have not scoped.

Honest section

What usually goes wrong

From programmes we have run and programmes we have been called in to rescue. Not one of these is exotic, and all of them are cheap to prevent and expensive to discover late.

Common migration failures, causes and prevention
What goes wrong	Why it happens	How we prevent it
Egress charges far above the model	Chatty components split across clouds or regions during a partial migration, plus backup and log shipping that crosses a boundary nobody costed	Dependency-complete waves, flow-log analysis before wave composition, and explicit modelling of cross-boundary traffic per wave
Licence costs wipe out the savings	Azure Hybrid Benefit does not apply on AWS; Software Assurance mobility terms are assumed rather than checked	Licence position review as a mandatory assessment deliverable, with vendor confirmation on anything ambiguous before cost sign-off
Third-party IP allowlists block the new environment	Payment gateways, banks, partner SFTP endpoints and legacy APIs allowlist your old egress IPs. Change requests on their side take weeks	Allowlist inventory during assessment, static egress IPs via NAT gateway or Global Accelerator, and partner change requests raised before the wave is scheduled
DNS TTLs too long at cutover	A 3,600-second or 86,400-second TTL means resolvers keep sending traffic to the old environment for hours after the switch	TTLs reduced to 60 seconds at least 14 days before cutover, verified from multiple public resolvers, then restored after acceptance
Hidden cross-region and cross-zone traffic	Load balancers, replicas and caches placed in different zones from their clients. Individually tiny, collectively a large monthly line item	Zone-aware placement in the target design, cross-zone traffic monitored as a first-class metric from wave zero
Direct Connect provisioning delays the programme	Cross-connect lead times of four to twelve weeks are discovered after the plan is signed	Circuit ordering starts during assessment. Waves that depend on it are sequenced last, with VPN as an interim path
Performance regresses after cutover	Rightsized on average utilisation rather than p95, or a managed service with different I/O characteristics than the self-managed original	Load testing against production-shaped data before cutover, p95-based sizing, and 30 days of headroom before any commitment purchase
Undocumented dependency breaks a wave	A batch job, a hard-coded IP, a scheduled task on a server nobody owns, or a spreadsheet that queries the database directly	Flow-log analysis over a period long enough to catch monthly jobs, plus a database connection audit by source address
The source environment never gets decommissioned	Nobody is willing to sign the switch-off, so you pay for both indefinitely	Decommission date and named approver in the wave exit criteria, with data archived and restore tested before the date
WAF rules block legitimate traffic at cutover	Managed rule groups differ between providers and are enabled in blocking mode from the start	WAF deployed in count mode against mirrored production traffic for at least a week, tuned, then switched to blocking before the wave

Answers

Cloud migration and modernisation questions

What are the 7 Rs of cloud migration?

Retire, Retain, Rehost, Relocate, Replatform, Refactor and Repurchase. Each workload in an estate is assigned one disposition during assessment. Retire and Retain remove work from the programme before it starts, which is why we assess disposition before scoping anything. On a typical estate, 10 to 20 percent of workloads turn out to be retirable, and that is usually the cheapest saving in the whole programme.

How long does an Azure to AWS migration take?

Assessment takes three to five weeks. Landing zone and foundation work runs four to six weeks and overlaps the tail of assessment. Execution depends on wave count: a 40-workload estate typically runs five to seven waves over four to eight months. Databases and anything with a licence dependency dominate the timeline far more than application count does.

Can you migrate without downtime?

For most stateless and read-heavy workloads, yes, using DNS-based or load-balancer-based traffic shifting with both environments live. For transactional databases we use AWS DMS with change data capture to keep the target continuously current, then take a short cutover window measured in minutes to seconds while replication drains. Genuinely zero downtime on a single-writer relational database requires either a dual-write application change or accepting a brief write freeze, and we will tell you which one your architecture allows rather than claiming both.

Will our costs actually go down after migrating to AWS?

Only if the migration includes rightsizing and commitment planning. A pure lift-and-shift of Azure virtual machines to equivalently sized EC2 instances often costs slightly more, because Azure Hybrid Benefit and existing enterprise agreement discounts do not travel with you. Cost reduction comes from rightsizing against observed utilisation, Graviton where the workload supports it, savings plans on the proven baseline, storage tiering and removing the workloads that should be retired. We model this before you commit and validate it against real bills after.

What happens to our Microsoft licences when we move to AWS?

This needs checking per licence, per agreement, and it is where migration budgets most often break. Azure Hybrid Benefit does not apply on AWS. SQL Server and Windows Server licence mobility depends on your Software Assurance position and, for dedicated-host scenarios, on the terms applicable to your agreement. AWS offers licence-included EC2 options that avoid the question entirely but change the cost model. We require a licence position review as an assessment deliverable before any cost model is signed off.

Do you publish a full worked example?

Yes. We maintain a complete worked Azure-to-AWS migration proposal covering a representative mid-size estate: workload inventory with 7R dispositions, the full service mapping, wave plan with rollback gates, DMS and CDC approach, cutover runbook, cost baseline with before-and-after modelling, and the risk register. Request it via the contact page and we will send it, with no obligation and no sales sequence attached.

What is the difference between replatform and refactor?

Replatform keeps the application largely as it is but changes what it runs on: moving SQL Server to Amazon RDS, or containerising an IIS application onto ECS Fargate. Code changes are limited to configuration and connection handling. Refactor changes the application architecture itself: decomposing a monolith, adopting managed messaging, rewriting a component as serverless. Replatform typically delivers 60 to 70 percent of the operational benefit for 20 to 30 percent of the cost and risk, which is why we replatform far more often than we refactor.

How do you handle rollback if a wave goes wrong?

Every wave has a rollback gate with a pre-agreed decision owner, a defined trigger condition and a rehearsed procedure. Until a wave is formally accepted, the source environment stays running and authoritative-capable. Rollback is usually a DNS or load-balancer reversal plus reverse replication for any data written in the target. We rehearse the rollback in a non-production environment before the wave, and we do not proceed to cutover until the rollback has been executed successfully at least once.

Request the full Azure-to-AWS migration proposal

A complete worked example: workload inventory with 7R dispositions, the full service mapping, wave plan with rollback gates, DMS and CDC design, cutover runbook and validated cost baseline. Ask and we will send it, with no obligation.

Request the proposal Call +91 90687 14658

Continue exploring

Cloud & DevOps engineeringThe landing zone, pipelines and observability Data engineering & analyticsWarehouse and pipeline migration API integration & microservicesMonolith decomposition and messaging Cybersecurity & complianceControls and evidence in the target estate Technology stackCloud services we work in Case studiesMeasured migration outcomes