Compete Migration for ISVs: Real Costs, Risks, and What Microsoft Won't Tell You

Compete migration is the part of the ISV growth story that Microsoft pitches as a tailwind and your engineering team experiences as a year-long project.

Move customers from AWS or Google Cloud to Azure, the pitch goes, and Microsoft co-sell economics open up: migration funding, Marketplace Rewards, MACC eligibility, Microsoft seller engagement, the path to Azure IP co-sell eligible status. All of that is real. So are the costs, the risks, and a handful of operational truths that do not make it into the Microsoft slide deck.

What is compete migration for ISVs?

Compete migration for ISVs is the process of moving a software vendor's product and customer base from a competing cloud platform (typically AWS or Google Cloud) to Microsoft Azure, in exchange for access to Microsoft co-sell economics, migration funding, and Microsoft seller engagement. The motion combines engineering work (re-platforming on Azure) with go-to-market work (moving customers, qualifying for incentives, building Microsoft seller relationships).

The economic case is strong on paper. Microsoft programs including Azure Migrate and Modernize Partner-led for ISV, the Marketplace Transact and Grow Incentive Campaign, and the ISV ACR Growth Incentive Campaign collectively offer hundreds of thousands of dollars in funding for qualifying ISVs.

The risk case is also real. McKinsey research found that cloud migration inefficiencies cost the average company 14 percent more in migration spend than planned each year, with 38 percent of companies seeing their migrations delayed by more than one quarter. The Microsoft economics only pay back if the migration finishes close to plan.

The real costs of compete migration

Three cost buckets show up on the actual P&L of a compete migration. None of them are the line items most ISVs budget for first.

1. Engineering re-platforming and tooling

Re-platforming code from AWS-native or GCP-native services to Azure equivalents is rarely a clean swap. AWS Lambda becomes Azure Functions with subtle behavior differences. AWS IAM becomes Microsoft Entra ID with a different permission model. S3 becomes Azure Blob Storage with different egress economics. The data and AI platform layer often hides the largest re-platforming surprises. Add CI/CD pipeline updates, IaC rewrites, observability re-instrumentation, and security review for the new platform. A disciplined AI app innovation practice keeps this work bounded.

2. Customer-side migration costs

Each customer has to be moved off the old platform onto the new one. Customer-side costs include downtime windows, change management, training, support load during the transition, and data egress fees paid to the source cloud. Customers that resist migration become churn risk. ISVs that move customers in bulk without per-customer cutover planning find a percentage of the base unwilling to follow. The customer-migration line is almost always larger than the engineering line.

3. Parallel-run and dual-cloud operations

The recommended migration pattern keeps both clouds running in parallel during the transition. Microsoft's own architecture guidance for AWS-to-Azure calls out blue/green deployment as the default. Parallel-run protects the customer base from a botched cutover and adds three to nine months of double infrastructure costs, double observability tooling, and double on-call coverage. The risk reduction usually justifies the spend, but only when budgeted from day one.

The real risks of compete migration

Three risks decide whether the compete migration program pays back. All three are predictable and all three are commonly missed in the initial business case.

1. Customer churn during the migration window

The single biggest revenue risk in any compete migration is customer churn during the move. Customers that have built workflows around the AWS or GCP version hit friction during cutover. A small percentage churn naturally. Without a deliberate customer migration plan (per-customer cutover dates, dedicated success engineering, executive sponsorship), the churn rate can wipe out the funded migration economics. An honest AI build or buy review of customer migration tooling often surfaces ways to reduce friction.

2. Microsoft program rule changes mid-cycle

Microsoft updates its partner programs every fiscal year (July 1 to June 30). Funding caps, eligibility thresholds, and program names change. An ISV that starts a compete migration in Q1 FY26 expecting one set of incentives can finish in Q4 FY27 facing different rules. Microsoft's Ignite November 2025 announcement of App Accelerate, consolidating ISV Success, Marketplace Rewards, and co-sell into a single pathway, is one example of a structural change mid-program for ISVs already in flight.

3. Hitting the $100K ACR threshold on the program clock

Azure IP co-sell eligible status requires $100,000 in Azure Consumed Revenue or Marketplace Billed Sales over a trailing 12-month period. ISVs migrating their first cohort of customers often plan economics assuming IP co-sell eligibility is locked in by month six. The reality is that ACR builds up over time as migrated customers turn on real workloads. A focused compete migration engineering motion treats the threshold as a milestone to engineer toward, not an outcome to assume.

What Microsoft won't tell you about compete migration

Three operational truths matter to the economics and rarely surface in partner program decks. None of them are deal-breakers. All three are budget items.

1. Funding is post-spend reimbursement, not advance

Microsoft migration funding (Azure Migrate and Modernize Partner-led for ISV and most Marketplace Rewards components) is paid as reimbursement after the ISV has spent the money and proved the engagement. The cash flow profile: spend in Q1, file the claim in Q2, receive payment in Q3 or Q4. ISVs that model the funding as a deduction from upfront migration cost are mismodeling. The funding is real, but it lands later.

2. Co-sell handoff to Microsoft sellers is built, not automatic

Achieving co-sell ready or Azure IP co-sell eligible puts the ISV's solution in Microsoft's internal seller catalog. That is necessary but not sufficient. Microsoft sellers do not actively pitch every solution in the catalog. The handoff that drives real co-sell pipeline requires partner sales investment: a Microsoft channel motion built around named seller relationships, joint account planning, and joint customer references.

3. Time-to-full-economics is 12 to 18 months, not the next quarter

The full economic case of compete migration (re-platforming complete, customer base migrated, $100K ACR threshold hit, IP co-sell eligible, Microsoft sellers engaged, Marketplace Rewards delivering leads) takes 12 to 18 months from engineering kickoff. ISVs that promise the board a self-funding migration by month six set themselves up for a difficult Q3 update.

Run the math before you run the migration

Compete migration pays back when engineered from honest numbers and an 18-month plan. Compete migration loses money when sold to the board on the partner-program slide deck and then under-resourced on the engineering side. Run the cost-risk-truth checklist above against your ISV's situation before committing. If you want a second opinion from a team that has run compete migration motions for Microsoft ISVs at scale, start a conversation with Valorem Reply.