Problem Statement
The workflow helps a data engineer evaluate the downstream impact of a proposed schema change. It identifies which consumers may break, classifies the type of change, recommends mitigation strategies, and produces a communication and cutover plan. The goal is to ensure safe, predictable data migrations with minimal disruption.
Steps
Ingest Proposed Change
INGESTCollect the proposed schema modification, affected table or dataset, list of known consumers, and the current versioning or release strategy. Normalize all inputs and apply placeholders for internal assets.
Identify Downstream Consumers
EXECUTEMap all applications, dashboards, scheduled jobs, and reports that depend on the affected data. Incorporate both direct and indirect dependencies inferred from metadata or lineage.
Classify Impact
EXECUTEDetermine whether the proposed change is breaking or non-breaking based on type changes, removals, nullability, or schema shape alterations. Summarize consumer-specific risks.
Generate Mitigation Recommendations
EXECUTEProvide structured migration options such as compatibility views, dual-write strategies, backward-compatible fields, or versioned tables. Include a generic deprecation timeline template.
Create Communication Plan
EXECUTEDraft a cautious, migration-ready communication package outlining the change, risks, timelines, and expectations for affected teams.
Prepare Cutover Checklist
EXECUTEProduce a safety-first cutover checklist covering pre-migration validation, monitoring, rollback options, and confirmation steps.
Prompt Configurations
Schema Change Impact Analysis Prompt
You are assisting a data engineer in assessing downstream impact of a proposed schema change. Generate: (1) a complete impact map of consumers, (2) breaking vs non-breaking classification, (3) mitigation options including views, dual-write, and versioning, (4) a structured communication plan, and (5) a migration-safe cutover checklist. Use a cautious, structured, migration-ready tone. Use placeholders for internal asset names. Do not invent consumers that are not implied by the input. Always include a deprecation timeline template.
Example Inputs/Outputs
Proposed change: Rename column user_id to account_id. Dataset: analytics.user_events. Known consumers: dashboard 'User Activity Overview', ETL job 'Daily Event Aggregation'. Current versioning: none (in-place updates).
Impact map identifies the dashboard and ETL job, both flagged as breaking due to column rename. The workflow classifies the change as breaking because the old column will no longer exist. Mitigation recommendations include adding a temporary compatibility view exposing user_id, using dual-write fields during migration, and planning a versioned table if long-tail consumers exist. Communication plan includes notifying both consuming teams with expected dates, testing requirements, and a placeholder deprecation timeline. Cutover checklist includes pre-launch validation, verifying consumer updates, confirming backward compatibility of the temporary view, planned removal window, and rollback steps.