Attendance Compatibility and Backfill

Summary

Compatibility tooling moves Shift, weekly-off, and employee-assignment foundation data from the monolith into Attendance-owned storage while the systems coexist.

Audience

• Migration engineers, backend developers, QA engineers, architects, and release reviewers

Transition model

The specialized target context changes only Shift compatibility-identity generation so legacy identifiers can be preserved. The runner is source-read-only, target-upsert-only, batch-oriented, and idempotent by design. Dry run writes nothing. Resume uses completion markers; validate-only and post-run validators compare source and target counts/content for the supported scope.

This tooling does not migrate all Attendance objects and does not prove business parity outside its Shift/weekly-off/assignment scope. Dual ownership can create divergence during coexistence. Cutover requires parity, smoke, reconciliation, routing, rollback, and go/no-go evidence from the existing operational scripts. Rollback is an ownership/routing decision; deleting target data is not prescribed here.

Source References

• microservices/src/attendance-service/Backfill/ShiftPolicyBackfillCli.cs
• microservices/src/attendance-service/Backfill/ShiftPolicyBackfillTypes.cs
• microservices/src/attendance-service/Backfill/AttendanceMonolithSourceReader.cs
• microservices/src/attendance-service/Backfill/ShiftWeeklyOffBackfillRunner.cs
• microservices/src/attendance-service/Backfill/ShiftPolicyBackfillValidator.cs

Related Articles

• Attendance database
• Attendance technical documentation
• Attendance API documentation

See Also

• Attendance business documentation
• Attendance overview

Keywords

• Attendance persistence
• EF Core
• PostgreSQL

Revision Information

• Status: Draft
• Last reviewed: 2026-07-15
• Review cycle: Quarterly