Skip to content
All services
Cloud

Cloud migrations and cloud-native architecture.

AWS, GCP, Azure, and OCI as production targets. Migrations into the cloud, between clouds, or off a cloud you have outgrown. Landing zones, multi-account designs, FinOps after cutover, and an honest opinion on when multi-cloud is the wrong answer.

What we move

  • On-prem → cloud. Workload-by-workload assessment, dependency map, target-state design, IaC scaffold, networking, IAM blueprint, cutover sequencing. Common shapes: VMware / KVM workloads to EC2 / GCE / Azure VMs, on-prem databases to RDS / Aurora / Cloud SQL / Azure SQL, on-prem data warehouses to Redshift / BigQuery / Snowflake / Databricks.
  • Cloud → cloud. AWS ↔ GCP ↔ Azure ↔ OCI, whole-footprint or workload-level. The rare but real cases when an existing cloud just does not fit the application or finance shape any more.
  • Cloud-native rebuild. Lift-and-shift is sometimes the wrong answer. When workloads need re-architecting to actually pay for the move (cold storage tiers, serverless replacements, managed-service adoption), we re-architect alongside the migration. Done with a written architecture in the Appendix A so it is not a moving target.
  • Landing zone and account / subscription topology. AWS Control Tower / Landing Zone Accelerator, GCP Foundation, Azure Landing Zones — set up to your security and FinOps posture, not the vendor reference architecture verbatim.
  • Disaster recovery and business continuity. RPO / RTO budgeting per workload, cross-region replication topology, backup automation, restore-test scheduling, runbook authoring.

What you receive

  • Written cloud migration plan — workload inventory, dependency map, complexity tier per workload, target-state architecture, IaC scaffold approach, wave plan with sequencing constraints, 3-year TCO model.
  • Reconciliation evidence per wave — for any data move, row counts, schema parity, query-result diffs on a target sample. Same deterministic harness as our data-platform migrations.
  • Landing zone IaC scaffold — Terraform organized by environment, modular, baseline security guardrails wired up, multi-account governance posture documented.
  • Signed Appendix A — scope contract with the 90-day Scope Warranty.

How we price cloud engagements

Every cloud engagement starts with the same 10-day Discovery Sprint (₹2 – 3 L / $3 – 5k, 100% upfront). At day 10 you receive a written diagnostic, a recommended target-state, a wave plan with effort range, and a fixed Execution quote. Execution is milestone-billed (30% upfront / 40% mid / 30% on hypercare exit). Sign Execution within 60 days of Sprint delivery → 5% Combo discount applies.

What is out of scope

We do not handle network procurement (telco / interconnect contracts), end-user training programs, hardware decommissioning logistics, or vendor co-fund / migration grant paperwork beyond providing the technical artifacts your procurement team needs. If those are required we hand off cleanly — we do not bundle billing for work that is not cloud engineering.

Why this is not just lift-and-shift

The pattern we see across SI-driven cloud migrations: a 100% lift-and-shift that does not pay for itself, no FinOps work post-cutover, and an angry CFO at month six. We refuse to ship that shape. The Discovery Sprint deliberately surfaces which workloads should be retired (typically 15-25% of inventory), which need re-architecting before move (5-15%), and which are genuinely lift-and-shift candidates. Most of our cloud engagements end with a smaller cloud footprint and a lower bill than the source.

When multi-cloud is the wrong answer (and when it is right)

Multi-cloud is what executives ask for after one cloud-vendor lock-in scare. It is usually the wrong answer — the operational tax is real, the cross-cloud networking math is brutal, and the security surface area doubles. We tell you that up front. The cases where multi-cloud is genuinely right: a regulator requires it, a single-cloud incident is an existential risk for your business, or your workload mix has genuinely different cloud-cost profiles per workload. None of these apply to most of our clients; if they apply to yours, we design for it cleanly.

FAQ

Which clouds do you actually work with?

AWS, GCP, Azure, and OCI as production targets. We have built migration packs for AWS ↔ GCP, AWS ↔ Azure, and on-prem to AWS / GCP / Azure. Multi-cloud designs are a thing we do but tell you when not to.

How long does a cloud migration take?

Discovery Sprint is 10 business days fixed. Execution ranges from 8 to 24 weeks depending on workload count, complexity, and how much of the estate is genuinely worth migrating versus retiring or modernizing in place.

Do you handle the database migration as part of cloud migration?

Yes — most cloud migrations include a data layer move (Oracle / SQL Server / DB2 → Postgres or Aurora; Redshift / BigQuery / Snowflake moves). The data layer is explicit in Appendix A so it is never the surprise that breaks timeline.

What about FinOps after we are on the new cloud?

A FinOps audit is a separate 10-day engagement we ship after cutover. Most clients book it 30 days post-cutover when the bill has stabilized — that is when the savings are most surfaceable. See FinOps and Cost Reduction.

Who this is for

Does any of this sound familiar?

If it does, the next section explains how the engagement model is structured to address each one.

You did a lift-and-shift six months ago. The cloud bill is higher than what you were paying on-prem.

A lift-and-shift that doesn't pay for itself is a sign the workload composition was never analysed. Discovery flags which workloads should be retired, re-architected, or genuinely ported — before a single resource moves.

You've been told the migration will take 9 months. The vendor proposal is 400 pages of caveats.

The Discovery Sprint is 10 business days, fixed, and delivers a written wave plan and a fixed Execution quote. You know the scope, the sequencing, and the price before committing to anything.

You're locked into one cloud by a decision made three years ago. Now you need out — or a second opinion.

Cloud-to-cloud migrations (AWS ↔ GCP ↔ Azure ↔ OCI) are scoped per workload, not per vendor preference. Multi-cloud is usually the wrong answer; we'll tell you if it is and design the clean alternative.

Your landing zone was built by the cloud vendor's PS team. It doesn't match your security posture or FinOps requirements.

Landing zone re-architecture is a defined engagement. We build to your security and cost-allocation posture, not the vendor reference doc, with Terraform modular enough for your team to extend on day one.

Post-migration, costs spiked 30% in month two and nobody can explain the bill.

A FinOps review 30 days post-cutover — when the bill has stabilised — surfaces the named levers. Start with the free Cloud Cost X-Ray to see the shape before scoping deeper.

The Migration Engine

One discipline, every engagement.

Every migration runs the same six-stage pipeline: Inventory, Plan, Convert, Validate, Reconcile, Report. Human sign-off gates enforce the stage boundaries that matter.

STAGE 1 INVENTORY Read-only sweep STAGE 2 PLAN Wave + dependency map HUMAN GATE STAGE 3 CONVERT Rule library + handlers STAGE 4 VALIDATE Checksums + diffs STAGE 5 RECONCILE Daily diffs, parallel run STAGE 6 REPORT Co-signed cutover doc Scope sign-off required before conversion begins
Read how the engine works stage by stage
Why us

The rest of the market vs. what we do differently.

Every promise in this table lives in the contract, not the pitch deck.

Dimension Traditional T&M SI Replatform
Pricing model Time & materials — final cost unknown at project start Fixed-fee against a written Appendix A — no surprises
Staffing Senior pitched, junior delivered — bench economics drive the swap The engineer on the first call is the engineer in the repo
Validation Verbal sign-off or sampling — "it looks right" Deterministic row counts, checksums, query diffs — signed artefact you keep
Scope creep Absorbed into T&M — change orders often verbal, billed later Anything out-of-scope is a written Change Order before work begins
Timeline Months of ramp, discovery, re-discovery, re-scoping Fixed Discovery Sprint produces inventory + wave plan before you commit to execution
How to engage

How to start a cloud migration.

Start with a free cost read or go straight to a scoped sprint. Every step produces a written deliverable you keep regardless of what comes next.

01 · Free

FinOps Quick-Check

Free
2 minutes · no email

Six questions. Returns a monthly waste range and the named levers — useful for sizing whether your cloud cost problem warrants a full audit or just targeted fixes.

Run the Quick-Check
02 · Cost review

Cloud Cost X-Ray

Free
through Q3 2026 · 90-min live session

A live working session on your cloud bill. Named levers, a savings model, and a 30/60/90-day plan. After Q3 2026 it reverts to a $100 paid diagnostic, credited 100% to any execution engagement signed within 60 days.

Send me your bill
03 · Scoped sprint

Discovery Sprint

Fixed-fee
₹2–3 L / $3–5k · 10 business days

A structured 10-day sprint covering workload inventory, dependency map, target-state design, wave plan with effort range, and a fixed Execution quote. The deliverable is a written assessment report — yours to keep.

Start with a Discovery Sprint
04 · Execution

Cloud Migration

Contact
scope-quoted, fixed-fee · milestone-billed

Full migration execution against a written Appendix A produced by Discovery. On-prem to cloud, cloud to cloud, landing zone builds, cloud-native rebuilds. 90-day Scope Warranty on in-scope work.

Talk to us
Founder-led delivery

The people doing the work.

Yash Maheshwari
Founder · Replatform

Cloud and data platform engineer with 6+ years across migrations, lakehouse architecture, FinOps, and managed platform operations on AWS, GCP, Azure, Snowflake, Databricks, BigQuery, and Redshift. The engineer on your first call is the engineer in your repo — no bench hand-offs, no junior substitutions.

Not ready to talk?

Download the Migration Readiness Checklist

A structured list of what to have ready before starting a cloud migration — workload inventory, network topology, compliance constraints, stakeholder sign-off requirements.

Get the checklist