Skip to main content

Payroll Compatibility and Transition Storage

Summary​

Coexistence of monolith sources, Payroll storage, projections, compatibility contracts, and backfill.

Audience​

Payroll developers, QA and support engineers, solution and security architects, and implementation partners.

Purpose​

Explain confirmed transitional storage behavior without exposing legacy physical persistence details.

Ownership​

The monolith remains a read-only source for the backfill reader. PayrollDbContext is the write target. Compatibility APIs write Payroll-owned objects while presenting legacy-facing contracts.

Lifecycle​

The backfill runner processes workforce, salary components, statutory settings, advances, approved expenses, attendance, and leave; frozen Payroll history is optional and runs last. Work is tenant-batched, retried, resumable through audit evidence, and upsert-oriented. A dry run does not save targets.

Persisted fields​

Payroll uses its own record identities while retaining legacy employee/claim references where compatibility requires them. Projection records also retain last-event markers.

Relationships​

Identifier correspondence is scalar and application-managed; no foreign keys connect Payroll persistence to the monolith or upstream service stores.

Constraints​

Selected unique indexes protect target upserts. Backfill audit records mark tenant/step completion for resume behavior.

Indexes​

Compatibility queries use tenant plus legacy identifier, period, run, date, name, or claim indexes depending on object type.

Tenant behavior​

Backfill enumerates and processes tenants independently. Target upserts explicitly include tenant scope.

Audit behavior​

Backfill completion/failure evidence is separate from business command audit. Compatibility mutation coverage varies by operation.

Integration usage​

Events maintain projections after/alongside backfill. The code does not establish a distributed transaction between legacy reads, target writes, and event delivery.

Known limitations​

Native and compatibility lifecycle semantics are not fully uniform. Rollback from a partially progressed transition requires controlled reconciliation; automatic reverse synchronization is not confirmed.

Requires confirmation​

  • Cutover authority and final system-of-record dates per object family.
  • Rollback, reconciliation, and post-cutover correction procedure.
  • Retirement plan for legacy identifiers and compatibility endpoints.

Source References​

  • microservices/src/payroll-service/Infrastructure/PayrollDbContext.cs
  • microservices/src/payroll-service/Domain/PayrollEntities.cs
  • microservices/src/payroll-service/Infrastructure/Migrations/PayrollDbContextModelSnapshot.cs
  • microservices/src/payroll-service/Application/PayrollCompatService.cs
  • microservices/src/payroll-service/Backfill/PayrollBackfillRunner.cs
  • microservices/src/payroll-service/Backfill/BackfillStepBase.cs
  • microservices/src/payroll-service/Backfill/FrozenPayrollBackfill.cs

See Also​

Keywords​

  • Payroll database
  • Payroll Compatibility and Transition Storage
  • Payroll persistence

Revision Information​

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