30 Claude Prompts for Migration Plans

You are a technical program manager running a go live event. <context> We are cutting over [PRODUCT OR SYSTEM NAME] from the old environment to the new one this weekend and I need a checklist the on call team can follow minute by minute. </context> <inputs> - Cutover window: [START TIME] to [END TIME] - On call team members: [NAMES OR ROLES] - Systems involved: [LIST OF SYSTEMS] - Communication channel: [CHANNEL NAME, e.g. Slack war room] </inputs> <task> Produce a minute by minute cutover checklist covering pre cutover freeze, the cutover steps themselves, verification steps, and the go or no go decision point. </task> <constraints> Include an explicit go or no go decision point with the name of the person authorized to call it. List every step as a checkbox item. Do not skip the verification step after each major action. </constraints> <format> Return a checklist grouped under three headings, Before Cutover, During Cutover, and After Cutover, each item on its own line starting with a checkbox. </format>

You are a DevOps engineer handling a domain migration. <context> We are pointing [DOMAIN NAME] to a new hosting provider and need to avoid downtime or lost email during the DNS cutover. </context> <inputs> - Current DNS provider: [CURRENT PROVIDER] - New DNS provider: [NEW PROVIDER] - Records to migrate: [RECORD TYPES, e.g. A, MX, TXT] - TTL currently set: [TTL VALUE] </inputs> <task> Write a checklist for lowering TTL in advance, recreating every record on the new provider, verifying propagation, and confirming email and site traffic both still work after the switch. </task> <constraints> Lowering TTL must happen at least [NUMBER] hours before the cutover. Include a step to verify MX records specifically, since email breakage is often missed. Avoid assuming propagation is instant. </constraints> <format> Return a checklist with three sections, Before the Switch, During the Switch, and Verification, each with checkbox items and an estimated time for each step. </format>

You are a payments engineer switching processors. <context> We are moving live transaction processing from [OLD PROCESSOR NAME] to [NEW PROCESSOR NAME] and cannot afford failed or duplicate charges during the switch. </context> <inputs> - Transaction volume per day: [NUMBER] - Subscription or recurring billing involved: [YES OR NO] - Test mode validation completed: [YES OR NO] - Cutover date and time: [DATE AND TIME] </inputs> <task> Build a cutover checklist covering final reconciliation with the old processor, switching the live API keys, monitoring the first batch of transactions, and confirming refunds still work on both processors during the transition window. </task> <constraints> Include a step to keep the old processor active in read only mode for at least [NUMBER] days after cutover. Flag the specific risk of double charging a customer during the switch. Do not proceed if test mode validation is not confirmed complete. </constraints> <format> Return a checklist under three headings, Pre Cutover, Cutover Moment, and Monitoring Window, with a named owner next to each checkbox item. </format>

You are an infrastructure lead coordinating a physical data center move. <context> We are relocating servers from [OLD DATA CENTER LOCATION] to [NEW DATA CENTER LOCATION] and need a runsheet the on site team can execute step by step. </context> <inputs> - Equipment being moved: [LIST OF EQUIPMENT] - Transport window: [DATE AND TIME] - Backup verification status: [YES OR NO] - Emergency contact: [NAME AND PHONE NUMBER] </inputs> <task> Create a runsheet that sequences shutdown, physical transport, reinstallation, network reconnection, and service restart, with a confirmation step after each stage before moving to the next. </task> <constraints> Do not allow the transport step to start until backup verification is confirmed. Include estimated time for each stage. Name the person who must confirm each stage is complete before the next begins. </constraints> <format> Return a numbered runsheet with stage name, estimated duration, confirming owner, and a checkbox for completion. </format>

You are a release manager conducting a pre cutover readiness review. <context> Before we cut [APPLICATION NAME] over to the new environment, I need a structured review to confirm the team is actually ready, not just scheduled. </context> <inputs> - Planned cutover date: [DATE] - Teams involved: [LIST OF TEAMS] - Known open issues: [LIST OR NONE] - Rollback plan status: [DRAFTED OR NOT DRAFTED] </inputs> <task> Produce a readiness review that scores the cutover across code freeze status, testing completion, rollback plan existence, communication plan existence, and on call staffing, then gives a clear go or no go recommendation. </task> <constraints> Score each category as ready, at risk, or not ready, do not use vague language. If the rollback plan is not drafted, the recommendation must be no go regardless of other scores. Keep the review under 500 words. </constraints> <format> Return a scorecard table with category, status, and note, followed by a one paragraph go or no go recommendation. </format>

You are a database administrator preparing a rollback plan for a risky migration. <context> We are migrating [DATABASE NAME] to a new schema and need a documented way to revert if the migration causes data corruption or application errors. </context> <inputs> - Backup taken at: [TIMESTAMP] - Migration script location: [FILE PATH OR REPOSITORY] - Estimated rollback time: [TIME ESTIMATE] - Applications dependent on this database: [LIST OF APPLICATIONS] </inputs> <task> Write a rollback plan that specifies the exact trigger conditions for rolling back, the steps to restore from backup or reverse the schema change, and how to verify the rollback succeeded. </task> <constraints> State the maximum acceptable data loss window in minutes. List the specific error signals that should trigger a rollback decision, do not leave this to judgment alone. Include a step to notify [DEPENDENT TEAM] once the rollback is complete. </constraints> <format> Return three sections, Trigger Conditions, Rollback Steps, and Verification, with numbered steps in each section. </format>

You are a software engineer managing a risky feature rollout. <context> We shipped [FEATURE NAME] behind a feature flag to [PERCENTAGE]% of users and need a documented procedure for disabling it fast if metrics degrade. </context> <inputs> - Feature flag name: [FLAG NAME] - Flag management tool: [TOOL NAME] - Metrics being watched: [LIST OF METRICS] - Alert threshold: [THRESHOLD VALUE] </inputs> <task> Produce a rollback procedure that names the exact metric threshold that triggers disabling the flag, who is authorized to flip it, and what to communicate to the team once it is disabled. </task> <constraints> The procedure must work even if the person who built the feature is unavailable. Avoid assuming the on call engineer already knows the context, write it as if for a stranger. Keep the whole procedure to one page. </constraints> <format> Return a short runbook with headings Trigger, Action, Owner, and Post Rollback Communication. </format>

You are a procurement and systems analyst covering a vendor switch. <context> We recently switched from [OLD VENDOR NAME] to [NEW VENDOR NAME] and need a rollback plan in case the new vendor cannot handle our volume or fails a critical integration. </context> <inputs> - Old vendor contract status: [STILL ACTIVE OR TERMINATED] - Data exported from old vendor: [YES OR NO] - Integration points affected: [LIST] - Decision deadline for rollback: [DATE] </inputs> <task> Write a rollback plan covering how quickly we can reactivate the old vendor, what data needs to be re imported, and what breaks if we roll back after [DATE]. </task> <constraints> Be explicit about the point of no return, the date after which rollback is no longer realistic. Flag any cost implications of reactivating the old vendor. Do not recommend rollback as the default, treat it as a contingency only. </constraints> <format> Return a short memo with sections titled Point of No Return, Reactivation Steps, Data Restoration, and Cost Impact. </format>

You are a platform engineer writing a rollback runbook for an infrastructure change. <context> We are changing [INFRASTRUCTURE COMPONENT, e.g. load balancer configuration or container orchestrator] and need a documented way to revert quickly if the change causes an outage. </context> <inputs> - Change being made: [DESCRIPTION OF CHANGE] - Previous known good configuration: [LOCATION OR VERSION] - Deployment tool used: [TOOL NAME] - On call engineer: [NAME OR ROLE] </inputs> <task> Create a rollback runbook that lists the exact commands or steps to revert to the previous known good configuration, and how long the rollback should take. </task> <constraints> Include a verification step to confirm the rollback actually resolved the issue, not just that the commands ran. State what to do if the rollback itself fails. Do not include untested commands. </constraints> <format> Return a runbook with numbered steps, an estimated time per step, and a final section titled If Rollback Fails. </format>

You are an engineering manager building a decision guide for failed deployments. <context> Our team keeps debating whether to roll forward or roll back when a deployment causes problems, and I want a clear decision guide so we stop losing time in the moment. </context> <inputs> - Deployment frequency: [FREQUENCY] - Typical rollback time: [TIME ESTIMATE] - Severity levels used by the team: [SEVERITY SCALE] - Current incident process: [BRIEF DESCRIPTION] </inputs> <task> Write a decision guide that gives clear criteria for when to roll back immediately versus roll forward with a fix, based on severity and how long a fix would realistically take. </task> <constraints> Avoid leaving the decision purely to gut feeling, give at least three concrete criteria. Address the case where the root cause is unknown. Keep the guide to a single page that can be pinned in the team channel. </constraints> <format> Return a decision tree in text form, starting with the question Is [SEVERITY LEVEL] met, and branching to Roll Back or Roll Forward with the reasoning for each branch. </format>

You are a program manager reporting migration progress to executives. <context> I need to update [EXECUTIVE NAME OR TITLE] on the status of our [MIGRATION NAME] project, and they only have a few minutes to read it. </context> <inputs> - Current phase: [PHASE NAME] - Percent complete: [PERCENTAGE] - Biggest risk right now: [RISK DESCRIPTION] - Decision needed from leadership: [DECISION OR NONE] </inputs> <task> Write a short status update that states where the project stands, what risk could delay it, and what decision, if any, leadership needs to make this week. </task> <constraints> Keep it under 200 words. Do not bury the risk or the decision needed at the bottom, lead with them if they are significant. Avoid technical jargon the executive would not recognize. </constraints> <format> Return a short email with a one line subject, three short paragraphs, and a bolded line at the end stating any action needed from the reader. </format>

You are a customer communications specialist announcing a platform change. <context> We are migrating [PRODUCT NAME] to a new system and customers will experience [IMPACT DESCRIPTION, e.g. brief downtime or a login change] on [DATE]. </context> <inputs> - Impact on customers: [DESCRIPTION] - Downtime window if any: [WINDOW OR NONE] - Action customers must take, if any: [ACTION OR NONE] - Support contact: [CONTACT METHOD] </inputs> <task> Write a customer notice that explains what is changing, when it happens, what the customer needs to do, and where to get help if something goes wrong. </task> <constraints> Do not use internal terms like migration or cutover, describe it in plain customer language. Reassure without overpromising, do not claim there will be zero issues. Keep it under 150 words. </constraints> <format> Return the notice as it would appear in an email, with a subject line and a short closing line pointing to [SUPPORT CONTACT]. </format>

You are a project lead kicking off a migration project internally. <context> We are starting the [MIGRATION NAME] project and I need to align the whole team on scope, timeline, and roles before work begins. </context> <inputs> - Project goal: [GOAL DESCRIPTION] - Timeline: [START DATE] to [END DATE] - Team members and roles: [NAMES AND ROLES] - Known risks at kickoff: [LIST OF RISKS] </inputs> <task> Write a kickoff memo that states the goal, the timeline, who owns what, and the risks we already know about, so nobody starts the project with the wrong assumptions. </task> <constraints> Name specific owners for specific workstreams, do not leave ownership vague. Mention at least one known risk explicitly rather than glossing over it. Keep the memo to under 400 words. </constraints> <format> Return a memo with headings Goal, Timeline, Ownership, and Known Risks, each a short paragraph or bullet list. </format>

You are an IT communications lead announcing planned downtime. <context> We need to take [SYSTEM NAME] offline for [DURATION] on [DATE] as part of the migration, and I need to notify affected users in advance. </context> <inputs> - Affected users: [USER GROUP] - Downtime window: [START TIME] to [END TIME] - Reason for downtime: [BRIEF REASON] - Who to contact with questions: [CONTACT NAME OR TEAM] </inputs> <task> Write a downtime notification that states exactly when the system will be unavailable, why, and what users should do to prepare, such as saving work beforehand. </task> <constraints> State the time window in the recipient's likely local time zone or note that it varies. Do not use hedging language like might be affected when the outage is certain. Keep it to one short email. </constraints> <format> Return an email with subject line, one paragraph explaining the downtime, a bulleted list of what to do beforehand, and a closing line with the contact. </format>

You are a program manager closing out a migration project. <context> The [MIGRATION NAME] project is complete and I need to send a summary to both the team and the stakeholders who were tracking it. </context> <inputs> - Original goal: [GOAL DESCRIPTION] - Actual outcome: [OUTCOME DESCRIPTION] - Issues encountered: [LIST OF ISSUES OR NONE] - Next steps if any: [NEXT STEPS OR NONE] </inputs> <task> Write a closing summary that states whether the goal was met, what issues came up during the migration, and what happens next, if anything. </task> <constraints> Be honest about issues encountered rather than presenting the project as flawless. Thank the specific teams involved by name if provided. Keep it under 300 words. </constraints> <format> Return a summary with three short sections, Outcome, Issues Encountered, and Next Steps, suitable for pasting into an email or a shared document. </format>

You are a data engineer responsible for validating a migration before sign off. <context> We migrated data from [SOURCE SYSTEM] to [TARGET SYSTEM] and need a validation plan to confirm nothing was lost or corrupted before we decommission the source. </context> <inputs> - Record count in source: [NUMBER] - Key tables or fields to check: [LIST] - Known tricky fields, such as dates or currency: [LIST] - Validation deadline: [DATE] </inputs> <task> Produce a validation plan that checks record counts match, spot checks a sample of records field by field, and specifically tests the tricky fields listed for formatting errors. </task> <constraints> Require a sample size of at least [NUMBER] records for the spot check, not just a handful. Call out that record counts matching does not guarantee content is correct. Do not sign off on validation until both count and content checks pass. </constraints> <format> Return a validation checklist with three sections, Count Check, Sample Field Check, and Tricky Field Check, each with pass or fail criteria stated explicitly. </format>

You are a data analyst reporting on migration reconciliation results. <context> I ran a reconciliation between [SOURCE SYSTEM] and [TARGET SYSTEM] after migration and need to report the discrepancies found in a way the team can act on. </context> <inputs> - Total records compared: [NUMBER] - Discrepancies found: [NUMBER OR DESCRIPTION] - Types of discrepancies: [LIST, e.g. missing records, mismatched values] - Deadline to resolve discrepancies: [DATE] </inputs> <task> Create a reconciliation report that summarizes how many records matched, lists the discrepancies by type, and recommends which ones must be fixed before go live versus which can be handled afterward. </task> <constraints> Separate discrepancies into must fix now and can fix later, do not treat them all as equally urgent. Include the percentage of records that matched cleanly. Avoid rounding numbers in a way that hides the real discrepancy count. </constraints> <format> Return a report with a summary line stating the match percentage, a table of discrepancy types with counts, and a short recommendation paragraph. </format>

You are a solutions architect documenting a data mapping for migration. <context> We are mapping fields from [SOURCE SYSTEM] to [TARGET SYSTEM] and the engineering team building the migration script needs an unambiguous specification to work from. </context> <inputs> - Source fields: [LIST OF FIELDS] - Target fields: [LIST OF FIELDS] - Fields with no direct equivalent: [LIST OR NONE] - Transformation rules needed: [DESCRIPTION, e.g. date format changes] </inputs> <task> Write a data mapping specification that pairs each source field to its target field, states any transformation required, and flags fields with no direct equivalent for manual decision. </task> <constraints> Do not leave any source field unaccounted for, mark it explicitly if it will be dropped. State the transformation logic precisely enough that an engineer would not need to ask a follow up question. Flag any field involving personal data for extra review. </constraints> <format> Return a table with columns for source field, target field, transformation rule, and a notes column for anything needing manual decision. </format>

You are a data quality analyst auditing data before a migration begins. <context> Before we migrate [DATASET NAME] to [TARGET SYSTEM], I need to know how clean the source data actually is so we do not carry over garbage. </context> <inputs> - Dataset size: [NUMBER OF RECORDS] - Fields of concern: [LIST, e.g. email addresses, phone numbers] - Known data quality issues so far: [LIST OR UNKNOWN] - Tools available for the audit: [TOOL NAMES] </inputs> <task> Produce a data quality audit plan that checks for duplicates, missing required fields, invalid formats, and outdated records, then recommends whether to clean before migrating or migrate and clean after. </task> <constraints> State a clear threshold, such as a duplicate rate above [PERCENTAGE], that would justify cleaning before migration rather than after. Do not recommend migrating known bad data without at least flagging it. Keep the audit plan actionable, not just descriptive. </constraints> <format> Return a plan with sections Checks to Run, Findings Template, and Recommendation Threshold, each explained in a short paragraph or list. </format>

You are a records and compliance analyst planning data archival during a migration. <context> As part of migrating to [TARGET SYSTEM], we need to decide what historical data from [SOURCE SYSTEM] gets archived, migrated live, or deleted, in line with our retention rules. </context> <inputs> - Data retention policy: [POLICY SUMMARY] - Data age range in source: [DATE RANGE] - Regulatory requirements: [REQUIREMENTS OR NONE] - Archive storage location: [STORAGE LOCATION] </inputs> <task> Write an archival plan that classifies data by age and sensitivity, decides what gets migrated live versus archived versus deleted, and states how archived data can be retrieved later if needed. </task> <constraints> Follow the stated retention policy exactly, do not recommend deleting anything the policy requires keeping. Note any data that requires legal sign off before deletion. State the retrieval process for archived data in plain terms. </constraints> <format> Return a plan with a classification table showing data category, action taken, and retention period, followed by a short paragraph on retrieval process. </format>

You are a team lead facilitating a retrospective after a completed migration. <context> We just finished migrating [SYSTEM OR PROJECT NAME] and I want to run a retrospective that produces honest, useful input rather than generic praise. </context> <inputs> - Migration duration: [TIME PERIOD] - Major incidents during migration: [LIST OR NONE] - Team members involved: [NAMES OR ROLES] - Format preference: [MEETING OR ASYNC DOCUMENT] </inputs> <task> Create a retrospective structure with specific questions covering what went well, what went wrong, what surprised the team, and what should change for the next migration. </task> <constraints> Include at least one question that forces specificity, such as naming the exact moment things went sideways, rather than accepting vague answers. Do not let the retrospective turn into blame assignment, frame questions around the process, not individuals. </constraints> <format> Return the retrospective as a list of discussion questions grouped under Went Well, Went Wrong, Surprises, and Changes for Next Time. </format>

You are a site reliability engineer writing a runbook for the team on call after migration. <context> The migration of [SYSTEM NAME] just completed and the on call rotation needs a runbook covering the most likely issues in the first two weeks after cutover. </context> <inputs> - Known fragile components after migration: [LIST] - Monitoring dashboards to check: [DASHBOARD NAMES OR LINKS] - Escalation contact: [NAME OR TEAM] - Rollback plan reference: [DOCUMENT NAME OR LOCATION] </inputs> <task> Write a runbook that lists the most likely failure symptoms in the first two weeks after this migration, the diagnostic steps for each, and when to escalate versus handle it directly. </task> <constraints> Base the likely symptoms on the fragile components listed, do not write generic incident advice. State a clear escalation threshold, such as unresolved after [TIME PERIOD]. Reference the rollback plan location rather than repeating it in full. </constraints> <format> Return a runbook with a symptom, likely cause, diagnostic step, and escalation trigger for each of the top issues, formatted as a table. </format>

You are a program manager compiling a lessons learned report for future migrations. <context> We completed [MIGRATION NAME] and leadership wants a formal lessons learned report that other teams can use before their own migrations. </context> <inputs> - What went according to plan: [SUMMARY] - What deviated from plan: [SUMMARY] - Estimated versus actual timeline: [ESTIMATE] versus [ACTUAL] - Estimated versus actual cost, if tracked: [ESTIMATE] versus [ACTUAL OR UNKNOWN] </inputs> <task> Write a lessons learned report that compares planned versus actual outcomes, identifies the root cause of any major deviation, and gives concrete recommendations for teams planning similar migrations. </task> <constraints> Do not just describe what happened, explain why the deviation happened. Make recommendations specific enough to act on, not generic advice like communicate better. Keep the report to two pages or less. </constraints> <format> Return a report with sections Plan vs Actual, Root Causes, and Recommendations for Future Migrations, each with concrete detail. </format>

You are a risk manager maintaining a risk register for an active migration project. <context> I need a living risk register for the [MIGRATION NAME] project that the team updates as new risks emerge and old ones get resolved. </context> <inputs> - Known risks so far: [LIST OF RISKS] - Project phase: [CURRENT PHASE] - Risk owner assignment process: [DESCRIPTION] - Review cadence: [FREQUENCY, e.g. weekly] </inputs> <task> Build a risk register template that captures each risk, its likelihood, its impact, the mitigation plan, and the owner, and that can be updated on the stated review cadence. </task> <constraints> Score likelihood and impact on a simple scale, such as low, medium, high, do not overcomplicate the scoring. Every risk must have a named owner, not a team name. Include a column for status so resolved risks are visible, not deleted. </constraints> <format> Return a table with columns for risk description, likelihood, impact, mitigation, owner, and status. </format>

You are an operations lead documenting a vendor handoff after migration. <context> We finished migrating from [OLD VENDOR NAME] to [NEW VENDOR NAME] and need a handoff document so support and operations teams know how to work with the new vendor going forward. </context> <inputs> - New vendor support contact: [CONTACT INFO] - Escalation path: [DESCRIPTION] - Changed processes since the switch: [LIST] - Old vendor still needed for anything: [YES OR NO, DETAILS] </inputs> <task> Write a handoff document that explains how to contact the new vendor, what processes changed, and whether the old vendor is still needed for any lingering task. </task> <constraints> State the escalation path clearly enough that a new hire could follow it without asking questions. Do not leave ambiguity about whether the old vendor relationship is fully closed. List every process that changed, not just the major ones. </constraints> <format> Return a document with sections New Vendor Contact, Escalation Path, Process Changes, and Old Vendor Status. </format>