Write a project charter for a software migration

You are a programme manager who has led platform migrations.
I work in IT & Software: a software company that ships a SaaS product. This work matters to engineering leads, developers and IT buyers.

## Goal
Produce a one-document charter that gets sponsor sign-off for moving a system to a new platform.

## What matters in IT & Software
- People involved: product managers; engineering leads; DevOps and SRE engineers; the security team; customer success; IT buyers and procurement.
- Common risks to plan for: outages; data breaches and security holes; vendor lock-in; scope creep; knowledge held by one person; churn after a bad release.
- Documents people already work with: PRDs; technical design docs; runbooks; incident postmortems; release notes; security questionnaires.
- Timing and seasons: quarterly planning; release trains; annual renewal dates; end-of-quarter and fiscal-year-end deals.

## What I will give you
- System being migrated and the target platform: [SYSTEMS]
- Business reason for the move: [REASON]
- Budget and deadline: [BUDGET, DATE]
- Teams and people involved: [TEAMS]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the project's goal, scope, deadline, budget and team. Note the biggest unknowns.
2. Write the problem and the business case in plain words.
3. Define in-scope and out-of-scope items.
4. Set measurable success criteria, including cutover downtime and data accuracy.
5. Name roles: sponsor, owner, decision makers and approvers.
6. List assumptions, dependencies and constraints.
7. Outline phases and milestones.
8. List the top risks and how they will be managed.
9. List the top risks with likelihood, impact, owner and response.
10. Define how progress will be tracked and reported, and what triggers an escalation.

## What to deliver
- Project charter
- Success criteria table
- RACI for key decisions
- Milestone plan
- Risk register starter

## Expert rules
- Every task has an owner, an estimate and a clear done definition.
- Be honest about dates: show dependencies and the critical path, and add contingency.
- Write for busy stakeholders: decisions and blockers first, detail after.
- Respect uptime, security and data-protection requirements. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Use tables for plans, RACI, risks and timelines.
- Show dates and durations explicitly.
- Keep status text to short bullets with red, amber or green ratings where relevant.

## Before you answer
Check your draft against this list and fix anything that fails:
- Every task, risk and action has an owner role and a date or trigger.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on deployment frequency and uptime.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.