System Prompt Migration Plan Prompt

This prompt is for engineering leads and AI operations teams who are about to transition a production AI assistant from one system prompt version to another. The job-to-be-done is not just writing a new prompt, but producing a phased, testable, and reversible migration plan that accounts for backward compatibility, stakeholder communication, and rollback procedures. Use this when the policy change is significant enough that a simple cutover would risk silent behavioral regressions, user-facing breakage, or audit gaps. It is designed for teams that treat system instructions as living product contracts, not static configuration files.

The ideal user has access to the current system prompt, the proposed replacement, a set of behavioral test cases or eval suites, and knowledge of the deployment environment (e.g., canary infrastructure, traffic splitting, monitoring dashboards). Required context includes the risk tolerance of the product surface, any regulatory or compliance constraints on assistant behavior, and the list of stakeholders who must approve or be notified. Do not use this prompt for trivial wording changes, single-line fixes, or experimental prompts that have never been tested. It is overkill for pre-production prototyping. It is also not a substitute for a rollback decision prompt during an active incident—this plan is built before deployment, not during a fire.

The output is a structured migration plan, not a prompt diff or a behavioral analysis. If you need a side-by-side behavioral comparison first, use the System Instruction Version Comparison Prompt. If you need a go/no-go gate assessment, use the System Instruction Release Gate Prompt. This prompt assumes you have already decided to migrate and need the operational plan. After generating the plan, review it with your SRE and QA leads, load the testing gates into your CI/CD pipeline, and schedule the stakeholder communications before any traffic is shifted.

This template produces a structured migration plan for transitioning from one system prompt version to another. It is designed for engineering leads who need a cutover strategy, testing gates, rollback procedures, and stakeholder communication schedule—not just a diff of the two prompts. The prompt forces the model to reason about backward compatibility, phased rollout, and failure containment before producing the plan.

textCopy
You are a release engineering lead responsible for migrating a production AI assistant from one system prompt version to another. Your task is to produce a phased migration plan that minimizes user-facing disruption and provides clear rollback decision points.

## INPUTS

**Current System Prompt (Version [CURRENT_VERSION]):**

[CURRENT_SYSTEM_PROMPT]

codeCopy

**Target System Prompt (Version [TARGET_VERSION]):**

[TARGET_SYSTEM_PROMPT]

codeCopy

**Deployment Context:**
- Environment: [DEPLOYMENT_ENVIRONMENT]
- Traffic volume: [TRAFFIC_VOLUME]
- User-facing surface: [USER_SURFACE_DESCRIPTION]
- Regulatory constraints: [REGULATORY_CONSTRAINTS]
- Rollback latency: [ROLLBACK_LATENCY]

**Migration Constraints:**
- Maximum acceptable regression rate: [MAX_REGRESSION_RATE]
- Required testing gates: [REQUIRED_TESTING_GATES]
- Stakeholder approval chain: [APPROVAL_CHAIN]
- Freeze windows: [FREEZE_WINDOWS]

## OUTPUT REQUIREMENTS

Produce a migration plan in the following structure:

### 1. Behavioral Diff Summary
Categorize every change between the two versions as:
- **Breaking change:** Alters existing behavior users depend on
- **New capability:** Adds behavior not previously available
- **Constraint change:** Tightens or loosens existing restrictions
- **Tone/style shift:** Changes voice or refusal style without altering capabilities
- **No behavioral impact:** Structural or wording changes with identical behavior

For each breaking change, describe the user-visible impact and affected workflows.

### 2. Risk Assessment
- Highest-risk changes ranked by likelihood and severity of user harm
- Edge cases most likely to regress
- Multi-turn conversation scenarios that may degrade
- Tool-use or function-calling behaviors that may change
- Safety and refusal boundary shifts

### 3. Phased Rollout Plan
Define phases with explicit gates:

**Phase 0: Shadow Testing**
- Run target prompt on [SHADOW_TRAFFIC_PERCENTAGE] of logged production traffic
- Compare outputs against current prompt for behavioral equivalence
- Gate: Pass [SHADOW_PASS_CRITERIA] before proceeding

**Phase 1: Internal Canary**
- Deploy to internal users and [INTERNAL_CANARY_PERCENTAGE] of production traffic
- Monitor metrics: [CANARY_METRICS]
- Duration: [CANARY_DURATION]
- Gate: Pass [CANARY_PASS_CRITERIA] before proceeding

**Phase 2: Ramped Production**
- Increment traffic in steps: [RAMP_STEPS]
- Monitor at each step for [RAMP_MONITORING_DURATION]
- Gate per step: [RAMP_GATE_CRITERIA]

**Phase 3: Full Cutover**
- Complete migration to target version
- Retire current version after [DEPRECATION_WINDOW]

### 4. Rollback Triggers and Procedure
For each phase, define:
- Automatic rollback triggers (metric thresholds)
- Manual rollback decision criteria
- Rollback procedure steps
- Post-rollback investigation requirements
- Expected rollback duration

### 5. Testing Gates
- Pre-deployment tests that must pass
- Per-phase validation tests
- Regression test suite coverage requirements
- Adversarial and edge-case test requirements
- Multi-turn conversation test scenarios

### 6. Stakeholder Communication Schedule
- Who must be notified at each phase
- Communication templates for: pre-migration notice, phase transitions, rollback events, completion
- Escalation path for unexpected issues

### 7. Timeline
- Earliest start date accounting for freeze windows
- Phase durations
- Total migration window
- Deadline constraints

## CONSTRAINTS
- Do not propose skipping phases without justification tied to risk assessment
- Every rollback trigger must reference a specific observable metric
- Communication templates must include audience, channel, and timing
- If regulatory constraints exist, include compliance verification steps
- Flag any assumption you make about the deployment environment

Adapt this template by filling every square-bracket placeholder with concrete values from your deployment context. If a placeholder does not apply, replace it with a brief explanation of why it is omitted rather than leaving it empty. The prompt is designed to work with models that support structured reasoning before output; for smaller or faster models, consider splitting it into sequential calls—first the behavioral diff, then the risk assessment, then the phased plan—to avoid truncated outputs. Before deploying the generated plan, validate that every rollback trigger references a metric your observability stack actually captures, and that every testing gate maps to an existing test suite or one you can build before the migration begins.

This prompt is designed to be called programmatically as part of a policy release pipeline, not as a one-off chat interaction. The primary integration point is a CI/CD step that triggers when a new system prompt version is proposed for deployment. The application layer should supply the current and proposed system prompts, the target model identifier, and any known behavioral test results. The prompt's output—a structured migration plan—should be parsed as JSON and fed into downstream approval and orchestration systems.

Implement a validation layer that checks the returned JSON against a strict schema before the plan is accepted. Required fields include phases (an ordered array of rollout steps), cutover_strategy, backward_compatibility_measures, testing_gates, rollback_procedure, and stakeholder_timeline. Each phase must contain a step_name, traffic_percentage, duration, and success_criteria. If the model omits any required field or produces an unparseable structure, retry once with a more constrained [OUTPUT_SCHEMA] and a specific error message injected into [CONTEXT]. After a second failure, escalate for human review. Log every plan generation attempt with the model version, prompt hash, and validation result for auditability.

For high-risk migrations—such as changes to refusal policies, data access boundaries, or compliance rules—require a human approval step before any phase advances beyond 0% traffic. The harness should expose the generated plan in a review UI that allows an authorized engineer to approve, reject, or modify each phase. Wire the approval decision into your deployment system so that no canary rollout begins without a signed-off plan. Avoid treating this prompt's output as a final executable script; it is a planning artifact that must be reviewed, adapted to your specific infrastructure, and executed through your existing deployment tooling, not through the model directly.