Legacy IAM Parallel Run
Summary
Legacy IAM Parallel Run enables gradual migration from existing identity and access management systems to Keymate. Instead of a risky big-bang cutover, organizations run both systems in parallel, migrating users, organizations, and policies incrementally while maintaining service continuity and rollback capability.
Why It Exists
Migrating from a legacy IAM system presents significant challenges:
- Business continuity — Applications cannot tolerate authentication downtime
- Data complexity — User accounts, organizational hierarchies, and policies must transfer accurately
- Risk management — A failed migration affects all users simultaneously
- Validation — Teams need time to verify the new system before full cutover
Parallel run addresses these challenges by allowing both systems to operate simultaneously during the transition period, with controlled traffic shifting and comprehensive validation checkpoints.
Where It Fits in Keymate
Legacy IAM Parallel Run leverages multiple Keymate capabilities:
- Migration extensions — Import users, organizations, and department structures
- Runtime Sync — Keep credentials synchronized between systems
- Session Sync — Coordinate session termination across systems
- Identity federation — Route authentication to the appropriate system
Boundaries
What it covers:
- Organizational structure migration (tenants, organizations, departments)
- User account migration with attribute preservation
- Gradual traffic shifting strategies
- Credential synchronization during parallel operation
- Rollback procedures
What it does not cover:
- Application code changes (application teams handle their integration)
- Policy migration (handled separately through policy import tools)
- Real-time session sync (see Session Sync)
How It Works
Migration Phases
| Phase | Activities |
|---|---|
| Preparation | Inventory legacy data, map attributes, configure sync |
| Pilot | Migrate test users, validate authentication flows |
| Incremental | Migrate user groups progressively, monitor metrics |
| Cutover | Shift remaining traffic, decommission legacy system |
| Cleanup | Remove sync configurations, archive legacy data |
Data Migration Model
The migration extension imports the following entities:
| Entity | Description |
|---|---|
| Organizations | Top-level organizational units (tenants) |
| Departments | Hierarchical subdivisions within organizations |
| Users | User accounts with attributes and group memberships |
| Department templates | Reusable department structure definitions |
| Property templates | Custom attribute definitions |
Parallel Operation Patterns
| Pattern | Description | Use Case |
|---|---|---|
| Shadow mode | Both systems authenticate, Keymate logs but does not enforce | Initial validation |
| Percentage split | Route percentage of traffic to Keymate | Gradual rollout |
| User flag | Route based on user migration status | Controlled migration |
| Application split | Some apps use Keymate, others use legacy | Application-by-application |
Credential Synchronization
During parallel run, credentials must stay synchronized:
- User updates password in either system
- Sync provider detects the change
- Credential propagates to the other system
- Both systems accept the new password
Rollback Strategy
If issues arise during migration:
| Scenario | Action |
|---|---|
| Minor issues | Pause migration, fix issues, continue |
| Major issues | Route traffic back to legacy, investigate |
| Data corruption | Restore from migration checkpoint, retry |
Diagram
Example Scenario
Scenario
An organization migrates from a legacy identity system to Keymate. The migration proceeds department by department, with credential sync ensuring users can authenticate against either system.
Input
- Actor: Platform migration team
- Resource: Migration extension APIs
- Action: Incremental user migration
- Context: 10,000 users across 5 departments
Expected Outcome
- Department A migrates first (pilot)
- Validation confirms authentication works correctly
- Departments B through E migrate incrementally
- Credential sync maintains password consistency
- After final cutover, the team decommissions the legacy system
- Rollback was available at each checkpoint but not needed
Common Misunderstandings
- Parallel run requires duplicate infrastructure — Both systems share authentication traffic; you only need capacity for peak load, not double capacity.
- Migration is all-or-nothing — Parallel run specifically enables incremental migration with checkpoints and rollback.
- Sync is automatic — Credential sync requires explicit configuration and monitoring.
Credential synchronization must be configured before parallel run begins. Users changing passwords during migration without sync will experience inconsistent authentication.
Design Notes / Best Practices
- Start with a pilot group of low-risk users
- Monitor authentication success rates during migration
- Configure alerting for sync failures
- Document rollback procedures before starting
- Plan migration during low-traffic periods
- Keep legacy system operational until validation completes
Use the user flag pattern for maximum control — explicitly mark users as migrated rather than relying on percentage-based routing.
Related Use Cases
- Enterprise IAM consolidation
- Cloud migration of identity infrastructure
- Mergers and acquisitions identity integration
- Legacy system decommissioning