data-migration-and-platform-cutover

Name: data-migration-and-platform-cutover
Author: vaquarkhan

19stars4forks

How to install data-migration-and-platform-cutover?

vaquarkhan/data-engineering-agent-skills/data-migration-and-platform-cutover

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-migration-and-platform-cutover

Installs into the current project.

Summary

Guides agents through data migration and platform cutover workflows. Use when moving pipelines, tables, contracts, orchestration, or workloads between systems, clouds, warehouses, lakehouses, or serving layers.

Files · 1

View on GitHub

SKILL.md

1	# Data Migration And Platform Cutover
2
3	## Overview
4
5	Use this skill when the system is changing platforms or major architectural boundaries. It helps agents plan parallel runs, compatibility layers, validation, and safe cutover rather than treating migration as a one-day switch.
6
7	## When to Use
8
9	- migrating from one warehouse or lakehouse to another
10	- moving pipelines between orchestration or compute systems
11	- replatforming storage formats or table engines
12	- performing major serving-layer cutovers
13
14	Do not start cutover work without a rollback and validation path.
15
16	## Workflow
17
18	1. Define the migration scope.
19	Include:
20	- source platform
21	- target platform
22	- affected datasets and jobs
23	- compatibility expectations
24	- cutover window
25
26	2. Choose the migration pattern.
27	Common patterns:
28	- parallel run
29	- shadow validation
30	- phased consumer cutover
31	- bulk migration plus freeze window
32
33	3. Define validation gates.
34	Typical gates:
35	- row counts
36	- metric reconciliation
37	- freshness parity
38	- schema compatibility
39	- performance or cost acceptance
40
41	4. Make rollback real.
42	Rollback should be executable, not a sentence in a plan.
43
44	5. Retire the old path deliberately after confidence is established.
45
46	## Common Rationalizations
47
48	\| Rationalization \| Reality \|
49	\| --- \| --- \|
50	\| "We can switch everything at once during a quiet window." \| Hidden downstream dependencies often make big-bang cutovers fragile. \|
51	\| "If the data matches once, we are done." \| Cutovers also need sustained operational parity and recovery confidence. \|
52	\| "We can keep the old path around indefinitely just in case." \| Zombie dual paths create confusion and extra risk unless retired deliberately. \|
53
54	## Red Flags
55
56	- rollback is not executable
57	- consumer cutover is assumed rather than coordinated
58	- validation is limited to a one-time row count
59	- the old and new systems are both considered source-of-truth after cutover
60
61	## Verification
62
63	- [ ] Migration scope and target behavior are explicit
64	- [ ] The cutover pattern and validation gates are documented
65	- [ ] Rollback is real and tested where practical
66	- [ ] Old-path retirement is planned after stable adoption

People who liked this also viewed

6 picks

Type

data-migration-and-platform-cutover

19stars4forks

View on GitHub

How to install data-migration-and-platform-cutover?

vaquarkhan/data-engineering-agent-skills/data-migration-and-platform-cutover

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-migration-and-platform-cutover

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Migration And Platform Cutover
2
3	## Overview
4
5	Use this skill when the system is changing platforms or major architectural boundaries. It helps agents plan parallel runs, compatibility layers, validation, and safe cutover rather than treating migration as a one-day switch.
6
7	## When to Use
8
9	- migrating from one warehouse or lakehouse to another
10	- moving pipelines between orchestration or compute systems
11	- replatforming storage formats or table engines
12	- performing major serving-layer cutovers
13
14	Do not start cutover work without a rollback and validation path.
15
16	## Workflow
17
18	1. Define the migration scope.
19	Include:
20	- source platform
21	- target platform
22	- affected datasets and jobs
23	- compatibility expectations
24	- cutover window
25
26	2. Choose the migration pattern.
27	Common patterns:
28	- parallel run
29	- shadow validation
30	- phased consumer cutover
31	- bulk migration plus freeze window
32
33	3. Define validation gates.
34	Typical gates:
35	- row counts
36	- metric reconciliation
37	- freshness parity
38	- schema compatibility
39	- performance or cost acceptance
40
41	4. Make rollback real.
42	Rollback should be executable, not a sentence in a plan.
43
44	5. Retire the old path deliberately after confidence is established.
45
46	## Common Rationalizations
47
48	\| Rationalization \| Reality \|
49	\| --- \| --- \|
50	\| "We can switch everything at once during a quiet window." \| Hidden downstream dependencies often make big-bang cutovers fragile. \|
51	\| "If the data matches once, we are done." \| Cutovers also need sustained operational parity and recovery confidence. \|
52	\| "We can keep the old path around indefinitely just in case." \| Zombie dual paths create confusion and extra risk unless retired deliberately. \|
53
54	## Red Flags
55
56	- rollback is not executable
57	- consumer cutover is assumed rather than coordinated
58	- validation is limited to a one-time row count
59	- the old and new systems are both considered source-of-truth after cutover
60
61	## Verification
62
63	- [ ] Migration scope and target behavior are explicit
64	- [ ] The cutover pattern and validation gates are documented
65	- [ ] Rollback is real and tested where practical
66	- [ ] Old-path retirement is planned after stable adoption

People who liked this also viewed

6 picks

Type