The Migration Review ends with a Migration Analysis if the call confirms strong fit. It is the document that goes back to your finance lead, CTO, or board - whoever needs enough context to approve the pilot internally.Documentation Index
Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
What’s in it
A typical Migration Analysis is a deeper decision document and includes:- Audit snapshot - year-one recovery, steady-state ongoing recovery, and cash-flow injection figures, reconfirmed against what surfaced on the call
- Why your app appears pilot-ready - reachability, technical readiness, store-policy fit, geo/cohort/timing specifics, and known risks
- Likely first pilot cohort - tenure profile, plan mix, geo bucket, and why that cohort is a safe starting point
- Technical readiness checklist - entitlement access, Stripe Connect, DNS, analytics fields, webhook readiness, and expected engineering hours
- Pilot terms - reservation amount (from $10K, scaled to your migration project), credit against migration, pre-kickoff refund window, implementation window, and what the pilot covers
- Reservation path - the offered implementation window, payment path, and what has to happen before kickoff
What it deliberately leaves out
The Migration Analysis is not a full migration runbook. It does not include:- Cohort sequencing in operational detail
- Offer strategy - pricing, incentives, plan-change options, or migration offer structure
- Email cadence and copy - the actual messaging composed for each wave
- Implementation architecture - detailed webhook flows, edge cases, dunning rules, and support runbooks
Who it’s written for
The summary is written for an internal reviewer who wasn’t on the Migration Review call. It assumes:- They’ve seen the audit numbers
- They have a baseline understanding of what migration is
- They want to know “is this real, is the path safe, what does kickoff look like”