메뉴
Database and API migration planning with zero-downtime strategies, rollback procedures, and data transformation
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/InugamiDev/ultrathink-oss --skill migration-planner명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Unified design foundations — design system architecture, tokens, component specs, visual principles, creative vision, figma integration, plus brand design system loader (66 real brands via DESIGN.md). Absorbs design, design-system, design-systems, design-principles, design-router, creative-vision, figma, design-md.
Render, summarize, and present markdown documents and structured content in multiple output modes
Ultra UI skill - combines Google's DESIGN.md spec (machine-readable design tokens) with the ui-ux-pro-max knowledge base (91 styles, 161 palettes, 73 font pairings, 161 products, 104 UX guidelines, 25 chart types). Generates lint-clean DESIGN.md files, validates token references and WCAG contrast, exports Tailwind/DTCG tokens, and diffs design systems version-over-version.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | migration-planner |
| description | Database and API migration planning with zero-downtime strategies, rollback procedures, and data transformation |
| layer | utility |
| category | development |
| triggers | ["migration plan","database migration","schema migration","API migration","zero downtime migration","data migration","breaking change"] |
| inputs | [{"current_state":"Current schema, API version, or system architecture"},{"target_state":"Desired end state after migration"},{"constraints":"Downtime tolerance, data volume, rollback requirements"},{"dependencies":"Systems and services affected by the migration"}] |
| outputs | [{"migration_plan":"Step-by-step migration plan with phases"},{"rollback_plan":"How to reverse each phase if something goes wrong"},{"risk_assessment":"Identified risks and mitigation strategies"},{"testing_checklist":"Verification steps for each migration phase"},{"timeline":"Estimated duration and resource requirements"}] |
| linksTo | ["data-modeling","postgresql","drizzle","prisma","api-designer"] |
| linkedFrom | ["plan","data-modeling","ship"] |
| preferredNextSkills | ["data-modeling","drizzle"] |
| fallbackSkills | ["sequential-thinking"] |
| riskLevel | high |
| memoryReadPolicy | selective |
| memoryWritePolicy | selective |
| sideEffects | ["Migration scripts may modify database schema","Data transformations may alter existing records"] |
Plan safe, reversible migrations for databases, APIs, and system architectures. This skill produces step-by-step migration plans that minimize downtime, prevent data loss, and include rollback procedures at every phase. The core principle: every migration step must be independently reversible.
SAFE (no downtime, no risk):
- Add a new table
- Add a new nullable column
- Add a new index CONCURRENTLY
- Add a new API endpoint
- Add a new enum value (append only)
CAUTION (requires coordination):
- Add NOT NULL constraint (backfill NULLs first)
- Add UNIQUE constraint (verify no duplicates first)
- Rename a column (expand-contract pattern)
- Change column type (expand-contract pattern)
- Deprecate an API endpoint
DANGEROUS (requires downtime or extreme care):
- Drop a column
- Drop a table
- Remove an API endpoint
- Change primary key type
- Merge or split tables
The safest pattern for any breaking schema change:
EXPAND PHASE (backward compatible):
1. Add the new column/table alongside the old one
2. Deploy code that writes to BOTH old and new
3. Backfill existing data from old to new
4. Deploy code that reads from new, writes to both
CONTRACT PHASE (remove old):
5. Deploy code that only uses new
6. Drop the old column/table
7. Clean up dual-write code
Each step is independently deployable and reversible.
## Migration Impact Assessment
### What is changing?
- [ ] Database schema (columns, tables, types, constraints)
- [ ] API contract (endpoints, request/response shapes)
- [ ] Data format (serialization, encoding, structure)
- [ ] Infrastructure (services, databases, queues)
### What depends on the changing component?
- Services: [list all consuming services]
- Clients: [frontend apps, mobile apps, third-party integrations]
- Jobs: [background workers, cron jobs]
- Reports: [analytics queries, dashboards]
### Data volume
- Rows affected: [count]
- Estimated migration time: [duration]
- Can it run online (without locking)? [yes/no]
Zero downtime required? [yes/no]
Maintenance window available? [day/time/duration]
Step 1: Add new column
SQL: ALTER TABLE users ADD COLUMN full_name TEXT;
Risk: None (additive)
Rollback: ALTER TABLE users DROP COLUMN full_name;
Step 2: Backfill data (batched)
SQL: UPDATE users SET full_name = name WHERE full_name IS NULL;
Run in batches of 1000 to avoid locking
Rollback: No-op (old column still has data)
Step 3: Deploy dual-write code
App writes to both `name` and `full_name`
App reads from `full_name` with fallback to `name`
Rollback: Revert deploy
Step 4: Add NOT NULL constraint
SQL: ALTER TABLE users ALTER COLUMN full_name SET NOT NULL;
Only after backfill verified complete
Rollback: ALTER TABLE users ALTER COLUMN full_name DROP NOT NULL;
Step 5: Deploy read-from-new-only code
App reads only from `full_name`, still writes to both
Rollback: Revert deploy
Step 6: Drop old column (1 week after Step 5)
SQL: ALTER TABLE users DROP COLUMN name;
Rollback: Re-add column and backfill from full_name
Step 7: Clean up dual-write code
Remove all references to old column
For large data migrations, process in chunks to avoid table locks:
async function batchMigrate(options: {
batchSize: number;
delayMs: number;
dryRun: boolean;
}) {
let cursor: string | null = null;
let totalProcessed = 0;
do {
const batch = await db.query(
`SELECT id, name FROM users
WHERE full_name IS NULL
${cursor ? 'AND id > $2' : ''}
ORDER BY id LIMIT $1`,
cursor ? [options.batchSize, cursor] : [options.batchSize]
);
if (batch.rows.length === 0) break;
if (!options.dryRun) {
const ids = batch.rows.map(r => r.id);
await db.query(
`UPDATE users SET full_name = name WHERE id = ANY($1)`,
[ids]
);
}
cursor = batch.rows[batch.rows.length - 1].id;
totalProcessed += batch.rows.length;
console.log(`Processed ${totalProcessed} rows`);
await new Promise(r => setTimeout(r, options.delayMs));
} while (true);
console.log(`Migration complete: ${totalProcessed} rows`);
}
Month 0: Release v2 API alongside v1
Month 1: Add Deprecation headers to v1 responses
Month 3: Email/notify all v1 consumers
Month 6: v1 returns 410 Gone for new consumers
Month 9: v1 fully sunset
Response headers during deprecation:
Deprecation: true
Sunset: Sat, 01 Sep 2026 00:00:00 GMT
Link: <https://api.example.com/v2/docs>; rel="successor-version"
CREATE INDEX CONCURRENTLY does not lock the table| Pitfall | Impact | Fix |
|---|---|---|
| DROP COLUMN same deploy as code | App crashes reading missing column | Separate deploys by at least one cycle |
| Large UPDATE without batching | Table locked for minutes/hours | Batch in chunks with delays |
| No rollback plan | Stuck with broken state | Write rollback SQL for every step |
| Testing on small dataset | Migration takes 100x longer in prod | Test with production-sized data |
| Missing index on new FK | Slow joins after migration | Always add index with FK column |
| NOT NULL without backfill | Migration fails on existing NULLs | Backfill first, then add constraint |
| No communication plan | Consumers surprised by breaking changes | Notify stakeholders before, during, after |