Adobe Platform Migration Program
Overview
Analyze and execute a multi-workload migration into or across Adobe services with contract evidence, dependency waves, dual-run reconciliation, cost controls, and rollback. This workflow produces a reviewable artifact and evidence before any live side effect.
Prerequisites
- Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
- Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
- Synthetic or approved non-production fixtures with secret and content canaries.
Current Contract
A migration is a set of product-specific contracts, not an endpoint translation. Auth ownership, entitlement, async behavior, input/output fidelity, storage custody, content rules, limits, events, and operational tooling must each map from source to target. Recheck the dated evidence map before relying on mutable product behavior.
Authentication
Choose S2S or user auth per data owner, not migration convenience. Preserve source/target identity and access evidence and never copy secrets or production content into test fixtures.
Instructions
- Inventory source workflows, volumes, identities, data classes, formats, SLAs, costs, dependencies, and retirement constraints.
- Map each capability to current Adobe service/version or classify it as gap, redesign, or retire; exclude EOL products.
- Define adapters, canonical data contracts, idempotency, provenance, reconciliation, storage, and rollback boundaries.
- Build synthetic and sampled approved parity tests for outputs, metadata, ordering, policy, latency, and cost.
- Migrate in dependency waves with shadow/dual-run only where duplicate actions and spend are controlled.
- Reconcile every wave, cut over from explicit thresholds, archive receipts, and remove approved obsolete paths and credentials.
Tool Discipline
Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.
Approval Boundaries
Program, identity, security, data, product, budget, and operations owners approve their waves. Live content movement, dual writes, cutover, and deletion require separate explicit approval.
Error Handling
- Do not claim parity from happy-path samples only.
- Do not map a retired Lightroom service to a different Lightroom API by name.
- Pause on count, content, provenance, authorization, or cost divergence.
Output
Return capability map, contracts, wave plan, test corpus, parity evidence, decisions, cutover/rollback, cleanup, and owners. Mark assumptions, observed environment behavior, owners, evidence dates, and unresolved gaps explicitly.
Examples
- Reconcile a synthetic PDF workflow across source and target.
- Classify a source capability with no current Adobe equivalent as a gap.
Validation
Exercise and record expected and observed results for:
- auth mismatch
- format drift
- policy difference
- duplicate action
- cost drift
- rollback
Resources
- Current first-party evidence map — recheck dated Adobe sources before execution.
- Treat observed tenant or product behavior as environment-specific evidence, never a universal Adobe guarantee.