Migration guide
Moving configuration between environments and platforms: deployment objects, IdentityIQ to Identity Security Cloud.
Migration covers two things: promoting configuration between IdentityIQ environments using deployment (export/import of objects), and the larger journey from IdentityIQ to Identity Security Cloud. Both succeed on clean, versioned configuration and a staged, tested approach.
- Environment promotion uses object export/import
- Keep configuration versioned and portable
- IIQ to ISC is a re-platform, not a copy
- Map concepts: rules become transforms/workflows
- Stage and test every migration
Migration covers moving SailPoint configuration and, sometimes, whole environments, between instances (development to test to production) or from one platform to another, in a controlled, repeatable way. Done well it is routine; done ad hoc it is a source of outages.
Configuration migration
IdentityIQ configuration lives as XML objects. Migrating configuration between environments means exporting those objects and importing them, ideally through source control and an automated deployment process, so promotions are repeatable and reversible.
A disciplined promotion path
- Develop and test configuration in lower environments.
- Export configuration as XML into source control.
- Promote through environments via a defined deployment process.
- Verify object references and run smoke tests after each import.
Environment and platform migrations
Larger migrations, new hardware, a cloud move, or a platform change, add database migration and connectivity re-establishment. Treat these like a project: plan, rehearse in a lower environment, and validate thoroughly before cutover.
Common pitfalls
- Hand-carrying XML between environments without source control.
- Breaking object references during import.
- No verification after promotion.