# Migration Strategy Prover MCP for AI Agents AI Agent Connect > Migration Strategy Prover prevents your AI from suggesting dangerous 'big-bang' database migrations without a plan. It forces the agent to map every dependency, define specific rollback triggers, verify row counts and checksums, and align all stakeholders. If the strategy isn't production-ready, the tool rejects it, forcing the AI to fix the gaps before you ever hit execute. ## Overview - **Category:** devops - **Price:** Free - **Endpoint:** https://edge.vinkius.com/vk_preview_HzTq9q2UIqKKaEu0iNhVd2uraFUN0e9iMnUfETqt/ai-agent-connect - **Tags:** migration-strategy, database-migration, cloud-migration, strangler-fig, rollback, data-integrity, cutover, sre ## Description When you ask an AI to move a database, it usually gives you the easiest answer, not the safest one. It might tell you to just dump the data and restore it, completely ignoring the fact that five different services rely on that data or that your backup is six hours old. This Connector acts as a mandatory gatekeeper for your migration plans. Instead of letting your agent hand-wave away the risks, it forces the agent to do the heavy lifting. It makes the AI prove it knows who is affected, exactly what happens if things go south, and how the data stays consistent during the move. It catches the 'everyone knows' attitude and replaces it with a published runbook and a list of specific teams. If the AI tries to skip a step, like forgetting to check for timezone mismatches or failing to define a go/no-go gate, the tool flags it immediately. It is built to stop the kind of 72-hour incidents caused by 'straightforward' migrations that were not actually straightforward. It forces a structured reflection on every move, requiring specific metrics for triggers and clear strategies like Canary or Blue-Green. By using this through the Vinkius catalog, you turn your AI from a source of risky suggestions into a rigorous migration engineer that will not let you make a mistake. It ensures that 'just switch back' is never an acceptable answer when data has already been mutated. ## Tools ### validate_migration_strategy Forces the AI to inventory risks, define rollbacks, prove integrity, plan cutovers, and align stakeholders. It rejects any plan that doesn't meet these five specific production standards. ## Prompt Examples **Prompt:** ``` We need to move our Postgres DB to the cloud this weekend. It should be easy. ``` **Response:** ``` ### RISK_UNASSESSED 'Easy' and 'just dump and restore' are not risk assessments. Before we proceed, we need to answer the following: * **Dependencies:** How many services query this database? Do any use RDS-specific features like `pg_cron` or IAM auth? * **Data Volume:** What is the total size? How long will the dump actually take? * **Blast Radius:** What happens to the billing pipeline if the connection string is slightly off? Please map these dependencies before we draft the migration plan. ``` **Prompt:** ``` How do we move the billing data without downtime? ``` **Response:** ``` ### MIGRATION_PROVEN I have validated a production-grade migration strategy: | Phase | Action | Monitoring Gate | |---|---|---| | **1. Prep** | Create read replica on Cloud SQL | | **2. Canary** | Route 10% of read traffic | | **3. Expansion** | Route 50% of read traffic | | **4. Cutover** | Write cutover with 2-min window | **Rollback Plan:** Triggered if error rate > 0.5% or p99 > 500ms. We will re-point connection strings via env vars in 3 minutes. ``` **Prompt:** ``` Can we just restore the old DB if the new one fails? ``` **Response:** ``` ### ROLLBACK_UNDEFINED 'Just switch back' is not a valid rollback plan when data has already been mutated. If the new database processed transactions, those records won't exist in the old one. **You need to define:** 1. **Trigger Metrics:** What specific error rate or latency triggers the rollback? 2. **Reconciliation:** How will you replay writes from the new DB back to the old one? 3. **Timeline:** How many minutes does the reversal take? ``` ## Capabilities ### Map downstream dependencies Identifies every service that reads from or writes to the database to prevent silent breaks. ### Define specific rollback triggers Sets hard metrics like error rates or latency for automatic reversals instead of vague plans. ### Verify data integrity Checks row counts, checksums, and referential integrity to catch bit-level corruption. ### Plan incremental cutovers Designs traffic shifting stages like Canary or Blue-Green with specific go/no-go gates. ### Align all stakeholders Forces the creation of a shared runbook and a list of every team that needs notification. ## Use Cases ### Moving from RDS to Cloud SQL A user asks for a simple dump and restore. The tool flags this as risky and forces the agent to plan a multi-phase traffic shift with monitoring. ### Monolith to Microservices Split An engineer wants to move a shared database. The tool catches that the monolith schema has diverged and forces a data reconciliation plan. ### Cloud Migration Data Integrity A team moves 80 million records. The tool forces the agent to check for Unicode truncation and timezone mismatches before the move starts. ### Schema Update Impact Analysis A developer wants to change a column type. The tool forces the agent to identify every ETL pipeline and downstream consumer that will break. ## Benefits - Stop 'big-bang' failures by forcing the agent to use Strangler Fig or Canary patterns via validate_migration_strategy. - Prevent data loss by requiring MD5 checksums and row count verifications during the integrity check. - Eliminate 'just restore from backup' excuses by making the agent define specific trigger metrics and reconciliation steps. - Avoid silent outages by requiring a full map of upstream producers and downstream consumers. - Ensure team alignment by forcing the creation of a shared runbook and escalation paths for all affected parties. ## How It Works The bottom line is your AI can't recommend a migration until it proves the plan is production-ready. 1. Provide your draft migration plan or requirements to your AI client. 2. The agent calls the tool to run a structured reflection on the strategy. 3. You get a MIGRATION_PROVEN status or a list of specific gaps to fix. ## Frequently Asked Questions **Can the Migration Strategy Prover help with my AWS to Google Cloud migration?** Yes, it validates the specific steps like connection strings, regional latency, and data volume to ensure your move to Google Cloud SQL is production-ready. **How does Migration Strategy Prover prevent data corruption?** It forces your AI agent to include MD5 checksums, row count verifications, and referential integrity checks as mandatory steps in the migration plan. **What happens if my migration plan is missing a rollback?** The tool will reject the plan and tell you exactly what metrics you need to define, such as error rates or latency, to ensure you have a real reversal plan. **Can Migration Strategy Prover map my service dependencies?** Yes, it requires the agent to identify every upstream producer and downstream consumer by name before the migration can be approved. **Is Migration Strategy Prover for all types of migrations?** It is specifically designed for high-stakes database and system migrations where data integrity and uptime are critical. **How does it help with stakeholder alignment?** It forces the agent to list every affected team and provide a shared runbook and escalation path, so no one is surprised by a service outage. **Does it execute migrations?** No. It validates that your migration plan covers risk assessment, rollback, data integrity, cutover, and stakeholder alignment. It does not run scripts or move data — it forces you to prove the plan survives a production failure. **What is the Strangler Fig pattern?** A migration strategy where you incrementally replace parts of the old system with the new one, routing traffic gradually until the old system handles zero requests. Named after strangler fig trees that grow around a host tree until it dies. It reduces blast radius because you migrate one capability at a time, with rollback at each stage. **Can it validate cloud-to-cloud migrations?** Yes. The 5 pivots apply to any migration: database, cloud provider, monolith-to-microservices, CMS, or data warehouse. Risk assessment maps provider-specific dependencies (IAM, networking, managed services). Data integrity addresses format differences. Cutover handles DNS, CDN, and traffic shifting. The framework is migration-type agnostic.