Recruitment Migrations and Seeding
Summary
Five migrations evolve the initial Recruitment model through compatibility, Employee handoff, Workflow reference, and offer/joining completion.
Audience
Developers, QA and support engineers, data reviewers, implementation partners, solution architects, and security reviewers.
Overview
Confirmed evolution
| Migration sequence | Source-backed purpose |
|---|---|
| 1 | Initial aggregate, child, evidence, processed-event, and outbox model |
| 2 | Compatibility identities and unique indexes |
| 3 | Onboarding Employee-reference state |
| 4 | Requisition Workflow reference and index |
| 5 | Offer letter/revision/approval children plus joining/document metadata |
The current snapshot represents the resulting model. A design-time factory creates the same RecruitmentDbContext; it is not a second persistence model. No backfill DbContext exists.
Development startup can apply migrations and run an idempotency-checked seeder; production comments require out-of-band migration application. Startup suppression exists. Exact configuration names, connection information, seed tenant, identities, personal data, dates, document references, and values are intentionally excluded.
Production approval, rollback rehearsal, backup/restore, compatibility data migration, and reconciliation are Requires confirmation.
Requires confirmation
Production migration governance, rollback ownership, reconciliation, retention, privacy, performance, query optimization, concurrency, and operational ownership require confirmation.
Source References
microservices/src/recruitment-service/Infrastructure/Migrationsmicroservices/src/recruitment-service/Infrastructure/DevelopmentSeeder.csmicroservices/src/recruitment-service/Infrastructure/Persistence.csmicroservices/src/recruitment-service/Program.cs
Related Articles
See Also
Keywords
- Recruitment database
- Migrations and Seeding
Revision Information
- Status: Draft
- Last reviewed: 2026-07-16
- Review cycle: Quarterly