Most release engineering literature treats a deployment window as a technical event: drain the traffic, run migrations, deploy, smoke test, rollback if needed. Blue-green, canary, feature flags — pick your flavor. The assumptions baked into this model are reasonable for SaaS products and e-commerce platforms. They are wrong for pension administration and insurance core systems.
In the BES (Bireysel Emeklilik Sistemi) world I spent years inside, a cutover window is not a downtime window. It is a regulatory boundary, a financial state-machine pause, and a reconciliation checkpoint — all happening simultaneously, all on someone else's clock.
The Window Is Not Yours
A standard release runbook starts with "choose a low-traffic window." For a pension system, there is no low-traffic window in the sense engineers mean. There is only a window where the consequences of state changes are less expensive to reverse.
Consider what is moving through a pension platform on any given night:
- Contribution files from employers, often submitted through SGK-linked channels with strict acknowledgment SLAs
- State subsidy (devlet katkısı) calculations that depend on the contribution date, not the processing date
- Fund price updates from custodian banks, which arrive on the custodian's schedule
- Policy state transitions: vesting milestones, retirement eligibility, surrender rights
- EGM (Emeklilik Gözetim Merkezi) reconciliation files that compare your participant balances to the central registry
None of these pause because you scheduled a deployment at 02:00. A contribution received at 23:55 belongs to one accounting day. The subsidy calculation tied to it belongs to another. The EGM file that reconciles both is generated on a fixed schedule and does not care whether your migration finished.
State Mid-Flight Is Not a Bug, It Is the Default
Standard release engineering assumes you can quiesce the system. Drain connections, finish in-flight requests, deploy. In a pension or insurance core, "in-flight" is a multi-day concept.
A contribution lifecycle can look like this:
- Employer submits file (day T)
- File validated, allocated to participant accounts (T or T+1)
- Fund units purchased at next available NAV (T+1 or T+2)
- State subsidy claim generated (T+2 to T+15 depending on cycle)
- EGM reconciliation confirms (T+N)
- Subsidy received and allocated (T+30 to T+60)
Deploying mid-cycle means deploying against records that are partially processed by code version N and will be finished by version N+1. If your schema migration changes how subsidy eligibility is computed, or how a fund allocation rounds to four decimals instead of six, you have just created a population of records that no version of your code fully understands.
This is not a hypothetical. I have seen reconciliation breaks that took three weeks to unwind because a deployment changed the rounding behavior of allocation logic on a Wednesday, and the EGM reconciliation on Friday flagged thousands of penny differences that all had to be traced, classified, and either corrected or formally disputed.
Rollback Is Often Impossible
The release engineering playbook treats rollback as a safety net. Deploy, observe, revert if needed. In insurance and pension systems, rollback after any financial state change is frequently impossible in the engineering sense.
You cannot un-purchase fund units. You cannot un-send a subsidy claim file. You cannot tell a participant their retirement eligibility was actually not granted yesterday. Once a transaction has been acknowledged externally — by a custodian, by EGM, by a regulator — your rollback is no longer a database operation. It is a compensating transaction, a correction filing, and often a regulatory disclosure.
This changes the calculus of every deployment decision:
- Feature flags must be designed so the flag flip itself is not a financial event
- Schema migrations must be backward-compatible across at least two cycles, not two deployments
- Smoke tests must verify reconciliation outputs, not just HTTP 200s
- "Successful deployment" is not measured at deploy time. It is measured at the next EGM reconciliation
What Actually Works
A few principles that survive contact with regulated reality:
Align cutovers with regulatory cycles, not engineering convenience. The right deployment window is often the gap between a reconciliation file going out and the next cycle starting. That might be a four-hour window on a specific weeknight. It is not negotiable to suit your sprint cadence.
Freeze upstream inputs explicitly. If you cannot stop contributions from arriving, at least stop them from being processed into the state machine until the new code is verified. Hold files in a quarantine queue. Resume processing only after post-deploy validation passes.
Version the business logic, not just the code. A contribution received under rules version 4.2 should be processable end-to-end under 4.2 even after the system has moved to 4.3. This is heavier than feature flags. It is essentially temporal logic embedded in the domain model.
Reconciliation is the real smoke test. A deployment is not done when the pods are healthy. It is done when the next EGM file matches, the next custodian reconciliation matches, and the next subsidy cycle clears. Anything less is wishful thinking dressed up as DevOps.
Treat the regulator as a stakeholder in the deployment plan. Major changes to calculation logic, even when functionally equivalent, often require notification or pre-approval. Engineering teams that discover this after deployment learn it expensively.
The Underlying Mismatch
Standard release engineering optimizes for deployment frequency and mean time to recovery. Pension and insurance core systems optimize for traceability, reversibility of business effect (not technical state), and regulatory defensibility. These are not the same objective function.
The industry has spent a decade telling everyone to deploy faster, smaller, more often. That advice is correct for most software. For systems where a deployment can create a participant balance discrepancy that has to be explained to a regulator six months later, the advice needs serious modification — or the team will eventually learn, through a reconciliation break or a formal finding, that the cutover window was never theirs to control.