Every few years a Turkish pension company decides its core BES platform has to go. The vendor is unresponsive, the architecture is from 2008, the actuarial engine cannot keep up with regulatory reporting cycles, and someone in the executive committee has finally signed the budget. A program starts. A systems integrator is picked. A cutover date lands on a slide.
And then, eighteen months later, the same slide gets pushed by another quarter. Then another. I have watched this happen more than once, and I have watched teams do genuinely excellent engineering work while the migration still slips. The reason is almost never the technology. It is that leadership treated the migration as if it were a core banking replacement or a policy admin swap, when it is neither.
A BES core platform migration is a legal continuity problem wearing an IT project costume.
Why the Usual Cutover Playbook Does Not Apply
In most enterprise migrations you have three viable strategies: big-bang cutover, phased rollout by product or region, or strangler-pattern replacement of one module at a time. All three assume that at any given moment there is one authoritative system of record for a given transaction.
BES does not give you that luxury. On any calendar day, for every participant, you must simultaneously be able to:
- Report an accurate participant balance to EGM (Emeklilik Gözetim Merkezi)
- Claim the correct state contribution (devlet katkısı) with a defensible calculation trail
- Honor a withdrawal, transfer-out, or fund switch request within regulatory SLAs
- Produce annual participant statements that reconcile to the kuruş with prior years
- Survive an SPK or Hazine inspection that samples any transaction from the last ten years
A big-bang cutover means all of that has to work in the new system on day one, including data that was written by workflows the new system never implemented. A phased rollout by product line means two systems are simultaneously the legal source of truth for different participants of the same sponsor — which is fine until a sponsor requests a consolidated report or a participant with two contracts transfers between them. A strangler pattern means the actuarial engine is doing calculations on data that is half in the old ledger and half in the new one.
None of these are impossible. They are just not projects you finish on a fixed date announced twelve months in advance.
Where Migrations Actually Fail
The conventional wisdom is that cutover weekend is where things break. In BES migrations, cutover weekend is usually fine. The team has been rehearsing for months, the runbook is exhaustive, the war room is staffed. What breaks is the six-month parallel-run period that precedes it, and the failure is almost always invisible until it is too late to fix.
Here is what parallel-run divergence looks like in practice:
- The old system rounds state contribution accruals at the fund level, daily. The new system rounds at the participant level, monthly. Both are defensible. Over six months and two million participants, the aggregate difference is in the low millions of TL. Nobody caught it because nobody was diffing at that granularity.
- A participant executes a fund switch on the old system on a Friday afternoon. The nightly replication to the new system runs before the switch settles. The new system has the participant in the old allocation. On Monday, the participant calls the call center — which is now reading from the new system — and is told their switch never happened. They execute it again. Now the new system has a duplicate switch that the old system never saw.
- The old system has a decade of manual adjustments booked as journal entries with free-text descriptions. The migration mapping handles the 40 documented adjustment types. It does not handle the 340 undocumented ones that were entered by operations staff who have since left.
Each of these individually is a rounding error. Together, six months in, the two systems no longer agree on what a participant's balance is, and there is no clean way to decide which one is right. That is the moment the program actually fails. Cutover just formalizes it.
The Reconciliation Path You Do Not Have
Ask any migration program manager what happens if the new system is discovered to be materially wrong two months after cutover, and you will get confident answers about rollback plans and backup snapshots. Ask them to walk through the specific case where a participant has, in that two-month window, made contributions, received state contributions, executed a fund switch, and taken a partial withdrawal — all recorded only in the new system — and now needs to be reverted to the old system as the legal system of record.
The honest answer is that there is no clean path. You cannot un-pay a state contribution. You cannot reverse an EGM submission that has already been accepted. You can compensate the participant, but you cannot restore the counterfactual world in which the migration never happened.
This is why the parallel-run period is not a testing phase. It is the actual project. If the two systems have not been in bit-for-bit agreement on participant balances, state contribution accruals, and EGM-reportable positions for a continuous ninety-day window before cutover, you do not have a defensible position with the regulator. You have a hope.
What Actually Works
A few things that I have seen make the difference between programs that finish and programs that slip forever:
- Treat divergence as a P1 incident from day one of parallel run. Not a variance to investigate at the next steering committee. A production incident with an on-call rotation and a same-day RCA. Any unreconciled kuruş at the participant level is a bug.
- Reconcile at the level regulators care about, not the level engineers find convenient. Fund-level totals matching is not sufficient. Participant-by-participant, transaction-by-transaction, with a signed-off hash of the day's positions on both systems.
- Freeze the old system's business logic during parallel run. No new features, no adjustment types, no undocumented fixes. Every change to the old system is a change to the migration scope. Most programs fail here because the business will not accept a freeze.
- Have the internal audit function sign off on the reconciliation methodology before parallel run begins. Not after. If your reconciliation approach would not survive an SPK inspection, it is not a reconciliation approach.
- Budget for a parallel-run period that is at least twice as long as the systems integrator proposed. They are optimizing for their contract. You are optimizing for the ten-year audit trail.
None of this is glamorous. None of it shows up well on a program dashboard. And all of it is the difference between a migration that finishes and a migration that becomes the reason the CIO leaves.
The Executive Conversation Nobody Wants to Have
When a BES core migration is proposed to a board, it is presented as an eighteen-to-twenty-four month program with a defined cutover. What it actually is: a three-year program in which the last twelve months are a legally binding dual-operation of two production systems, and the cutover is a formality at the end of a reconciliation period that has already succeeded or failed months earlier.
Boards that understand this fund the program correctly. Boards that do not, fund a project that will be re-planned three times and delivered late, and will be told each time that the technology is almost ready. The technology is almost always ready. The legal continuity is what nobody built a plan for.