Migration Workflow¶
This guide explains the complete AAP migration process.
Overview¶
AAP Bridge follows an ETL (Export, Transform, Load) pattern:
┌──────────┐ ┌───────────┐ ┌──────────┐ ┌────────┐ ┌─────────────────┐
│ Prep │───▶│ Export │───▶│Transform │───▶│ Import │───▶│ Synchronise │
└──────────┘ └───────────┘ └──────────┘ └────────┘ └─────────────────┘
Phase 1: Preparation¶
Purpose: Analyze both AAP instances and prepare for migration.
What happens:
- Connects to source AAP and fetches API schema
- Connects to target AAP and fetches API schema
- Compares schemas to identify field differences
- Generates transformation rules
- Saves prep data for subsequent phases
Output:
prep/source_schema.json- Source AAP schemaprep/target_schema.json- Target AAP schemaprep/schema_comparison.json- Field differences and transformations
Phase 2: Export¶
Purpose: Extract all resources from source AAP.
What happens:
- Exports resources in dependency order
- Handles pagination automatically
- Splits large datasets into multiple files
- Tracks export progress in state database
Export Order:
| Order | Resources |
|---|---|
| 1 | Organizations |
| 2 | Labels |
| 3 | Users, Teams |
| 4 | Credential Types, Credentials |
| 5 | Execution Environments |
| 6 | Inventories |
| 7 | Inventory Sources, Inventory Groups |
| 8 | Hosts |
| 9 | Instances, Instance Groups |
| 10 | Projects |
| 11 | Job Templates |
| 12 | Workflow Job Templates |
| 13 | Schedules |
Output Structure:
exports/
├── metadata.json
├── organizations/
│ └── organizations_0001.json
├── inventories/
│ ├── inventories_0001.json
│ └── inventories_0002.json
└── hosts/
├── hosts_0001.json
├── hosts_0002.json
└── hosts_0003.json
Phase 3: Transform¶
Purpose: Apply schema transformations for target AAP version.
What happens:
- Reads exported data
- Applies field mappings from schema comparison
- Removes deprecated fields
- Adds new required fields with defaults
- Validates transformed data
Transformations applied:
- Field renames (e.g., API changes between versions)
- Type conversions
- Default value injection for new required fields
- Removal of read-only fields
Phase 4: Import¶
Purpose: Load transformed data into target AAP.
What happens:
- Creates resources in dependency order
- Resolves foreign key references using ID mappings
- Uses bulk APIs where available (hosts)
- Handles conflicts (already exists)
- Tracks progress and creates checkpoints
Import Features:
- Bulk Operations: Hosts imported 200 at a time
- Idempotency: Skips already-migrated resources
- Conflict Resolution: Updates or skips existing resources
- Checkpointing: Can resume from any failure point
Phase 5: Validation¶
Purpose: Verify migration success.
What happens:
- Compares resource counts between source and target
- Validates field values match
- Checks relationship integrity
- Generates validation report
Checkpoint and Resume¶
Automatic Checkpoints¶
Checkpoints are created automatically during import:
- After each resource type completes
- At configurable intervals within large batches
Viewing Checkpoints¶
Resuming from Failure¶
# Resume from last checkpoint
aap-bridge migrate resume
# Resume from specific checkpoint
aap-bridge migrate resume --checkpoint inventories_batch_50
Resource Dependencies¶
Understanding dependencies is crucial for migration:
Organizations
├── Users (member of)
├── Teams (belongs to)
├── Credentials (owned by)
├── Projects (belongs to)
└── Inventories (belongs to)
├── Inventory Sources
├── Inventory Groups
└── Hosts
Credential Types (standalone)
└── Credentials (uses)
Execution Environments (standalone)
Job Templates
├── Project (uses)
├── Inventory (uses)
├── Credentials (uses)
└── Execution Environment (uses)
Best Practices¶
Before Migration¶
- Backup target AAP - Always have a rollback plan
- Test in staging - Run migration in a test environment first
- Check disk space - Exports can be large
- Verify credentials - Ensure API tokens have admin access
During Migration¶
- Monitor progress - Watch for errors in logs
- Don't interrupt bulk operations - Wait for completion
- Use checkpoints - Resume rather than restart on failure
After Migration¶
- Validate thoroughly - Run validation phase
- Test functionality - Run sample job templates
- Check RBAC - Verify user permissions
- Update credentials - Encrypted values need manual setup
Troubleshooting¶
See Troubleshooting Guide for common issues and solutions.