Cloud migration to AWS, Azure or Google Cloud

Last updated 27 September 2026

The 6 R's, one decision per workload

Each application gets one strategy. Forcing every system through a lift-and-shift, or every system through a rewrite, is how migration programs stall.

  • Rehost. Move with as little change as possible. This is the fastest route out of a data center when the application can tolerate it.
  • Replatform. Keep the business logic and change the platform underneath: managed databases, containers or a platform service.
  • Repurchase. Replace the product with a SaaS service that already performs the function, after a data-export plan is agreed.
  • Refactor. Re-architect for cloud-native scale, only where the business case pays for the engineering.
  • Retire. Switch off what nobody uses. Discovery often finds applications that still cost money and licences.
  • Retain. Leave it where it is, on purpose, and record the reason and a review date.

Discovery, TCO and wave planning

Nothing moves until discovery has a written output: an inventory, a dependency map, a total-cost comparison and a wave list. Discovery counts servers, licences, databases, file shares, identity, scheduled jobs and the people who know how each one runs. Dependencies set the wave order.

We do not pick a cloud first and then fit the workload to it. Discovery scores each application against the same criteria, and the result is written down per application:

  • Data location rules and contracts you already hold
  • Managed-service fit, such as a database engine your team already runs
  • Skills your team can operate after handover
  • Estimated run cost on each platform, with the migration cost counted
  • Exit path: how the workload would leave the platform later
CloudOur statusVerify
AWSAdvanced Tier Partner (Services). Not Premier.AWS Partner Finder, listing 0010h00001cA3jpAAC
Microsoft AzureDelivery partner for architecture, migration and operations. No Solutions Partner designation claimed.Microsoft partner directory, search TICON System Limited
Google CloudDelivery partner for architecture, migration and operations, including BigQuery, Vertex AI and GKE. No Partner Advantage tier claimed.Google Cloud partner finder

If the best answer for a workload is to stay where it is, the plan says so.

Data location is a design input, settled before any copy is made. Data-protection rules apply as applicable in your jurisdiction, including where personal data may live and how transfers are documented. No hyperscaler region is in Bangladesh, so if a workload must stay in a given country, discovery answers that question first. A cloud partner does not make you compliant with any regulation; your obligations stay with you.

Our partner status is listed so you can check it yourself:

Regions in our current working set are AWS Mumbai (ap-south-1) and Singapore (ap-southeast-1), Azure Central India, South India, West India and Southeast Asia, and Google Cloud asia-south1, asia-south2 and asia-southeast1. Other regions are confirmed per engagement.

The sequence, and what you still own

You decide or provideWe deliver
Go or no-go at each cutover, and the rollback decisionA written wave plan with rollback criteria
Application code changes and release timingReplication setup, cutover runbook, validation checklist
Data classification, retention and transfer approvals, with counselData-location options per platform and region
Licences tied to hosts or vendors, negotiated with each vendorA licence inventory from discovery
Compliance interpretation and audit responsesAn evidence pack for your reviewers
  1. Step 1:

    Discovery.

    An inventory, a dependency map and a total-cost comparison that counts staying put, dual running during waves and extra storage for replicas. The output is a wave list and a quote.

  2. Step 2:

    Landing zone.

    Accounts, subscriptions or projects, network, identity, logging, backup and cost controls, built before the first workload arrives.

  3. Step 3:

    Waves.

    Each wave has a defined scope, a copy or replication method, a validation checklist, a cutover window, a rollback trigger and a named owner who signs it off.

  4. Step 4:

    Validation.

    Functional, performance, security and cost checks against the list agreed in discovery.

  5. Step 5:

    Stabilize and hand over.

    Right-sizing once real load has run for a while, restore tests, and a handover into managed operations if you want it.

Each cloud has its own migration tooling, such as AWS Application Migration Service, Azure Migrate and Google Cloud Migrate to Virtual Machines. We use the native tool where it fits, and tool choice is made per wave.

Downtime approach and rollback

We do not promise zero downtime for the whole estate. Each wave has a cutover window, a rollback trigger and a named owner who signs it off. Some waves are near-zero because replication keeps the copy current. Others need a declared freeze, and we write its length into the plan.

Rollback has three stages, and each one costs more than the one before:

  • Before cutover. Traffic switches back. This is the cheapest stage, and little data is at risk.
  • After cutover, before the new system takes writes. The switch is reversed inside the window agreed for the wave.
  • After the new system accepts writes. Rolling back means a reverse sync or a restore from backup. It takes longer, and writes made after cutover may need reconciling. The wave plan states that exposure in hours and in data before cutover begins.

Some changes do not reverse cleanly: schema changes, third-party callbacks, DNS caches at clients and licences tied to a host. We list those in discovery so they are decided before the window opens, not during it.

Timelines by workload size

SizeTypical scopeCalendar time from kickoff
SmallA few servers or one application, no regulated data4 to 8 weeks
MediumSeveral applications, shared identity, one or two databases8 to 16 weeks
LargeMulti-application estate, often regulated, with some refactoring4 to 6 months

These are planning ranges for a funded team, measured in calendar time rather than effort-days. The quote follows discovery and replaces these ranges with the timeline for your estate.

Funding and what the move costs

AWS Migration Acceleration Program (MAP) funding may apply to qualifying migrations. MAP is an AWS program, and eligibility and any funding are set by AWS for each engagement. We do not quote a co-funding percentage or a credit amount.

The professional-services price is a fixed quote after discovery. The run cost after cutover follows your cloud agreement, or partner billing where a contract includes it. Where partner billing applies, compute and storage pricing has typically come in 15 to 35 percent below list, and CloudFront bandwidth up to 40 percent lower. These are estimates, not a quote guarantee. Use the AWS pricing calculator for an indicative monthly run rate; it is not an invoice.

Costs that belong in the total-cost model: dual running during waves, licence mobility, extra storage for replicas, and the people who still test each wave. Leaving them out is how a cheap-looking lift becomes an overrun.

Quotes are in USD and quote-based. Other currencies are available by contract only; ask. Taxes apply as applicable in your jurisdiction and the contract.

Frequently asked questions

How long does a cloud migration take?

Small moves run about 4 to 8 weeks from kickoff including discovery, medium ones 8 to 16 weeks, and large regulated estates four to six months. These are planning ranges, not a quote.

What does a migration cost?

It depends on the workload count and which strategy each application needs. We quote in USD after discovery. Sample bills are not published here, and funding amounts are not guessed.

Can you migrate with zero downtime?

We plan near-zero cutover with replication and a rollback per wave. Some systems still need a declared freeze. We do not sell zero downtime as a whole-estate promise.

Do you migrate from data centers and VMware?

Yes. Data centers, VMware, other clouds and shared hosting are in scope. Databases move with the native replication service for the engine, where continuous replication is supported.

Can we pay in our local currency?

Quotes are in USD. Other currencies are available by contract only, so ask.

What are the 6 R's?

Rehost, replatform, repurchase, refactor, retire and retain. Each application gets one, decided in discovery.

Is MAP funding available?

Qualifying workloads can be assessed for MAP. AWS sets eligibility and any funding per engagement. This page does not publish a percentage of cost covered.

Sources

  1. About the migration strategies (6 R's) (opens in a new tab). AWS Prescriptive Guidance. Accessed
  2. AWS Application Migration Service (MGN) (opens in a new tab). AWS Documentation. Accessed
  3. AWS Migration Acceleration Program (MAP) (opens in a new tab). Amazon Web Services. Accessed
  4. Azure Migrate (opens in a new tab). Microsoft Learn. Accessed
  5. Migrate to Virtual Machines (opens in a new tab). Google Cloud. Accessed

Related services

This page is not legal advice. Confirm applicable requirements with your counsel and compliance team.