Version 1.0
Data Migration & Legacy Coexistence Strategy
How Amana's policy, member, claim, tariff, reinsurance and financial data will move from its legacy core system(s) into Toshfa OptimaX. It covers mapping, rehearsals, reconciliation to the legacy system and General Ledger, retention of historical tariff context, legacy coexistence and controlled decommissioning, with a business sign-off gate at each stage.
What this document answers
Amana's Risk Evaluation rated Domain 4.1 (Data Migration and Legacy System Transition) as No Match on all four risks, because no migration or coexistence evidence was included in the documents reviewed. This document supplies that evidence. It sets out the strategy, controls and sign-off gates that Toshfa OptimaX commits to, and the evidence Amana will receive at each gate.
It also covers the related migration points raised elsewhere in the evaluation: legacy-policy tariff handling, data retention, cutover readiness and post-go-live stabilisation.
| Risk ID | Risk (from evaluation) | Previous result | How this document addresses it | Section |
|---|---|---|---|---|
| 4.1-R1 | Migrated data is incomplete or inaccurate | No Match | Field-level mapping specification, profiling-led cleansing with a named-owner exception log, three full mock migrations, count and value reconciliation per entity | 05, 06, 08 |
| 4.1-R2 | Financial balances do not reconcile after migration | No Match | Four-level reconciliation framework, including balance reconciliation to the legacy sub-ledgers and General Ledger Trial Balance, with Finance sign-off as a go-live condition | 06 |
| 4.1-R3 | Historical tariff and transaction context is lost | No Match | Legacy tariffs loaded as closed, effective-dated versions; migrated premiums kept as charged and never recalculated; permanent legacy-to-OptimaX key cross-reference; migrated approval and endorsement history | 07 |
| 4.1-R4 | Legacy access and decommissioning are poorly controlled | No Match | Read-only coexistence period, controlled legacy access, retention archive, and a decommissioning checklist signed by Compliance, Finance, IT and Risk | 09, 10 |
| 1.6-R2 | Endorsements use an incorrect tariff or pricing basis | Partial | Endorsements on migrated policies priced from the policy's original tariff version, tested as a named UAT scenario | 07 |
| 2.2-R4 | Data retention and history are insufficient | Partial | Retention periods per data domain, set by Amana Compliance; history migrated or archived, never discarded | 03, 10 |
| 4.5-R3 / R4 | Critical defects at go-live; cutover readiness not shown | Partial | Go/no-go criteria, cutover runbook, dress rehearsal, tested rollback with a defined point of no return | 08 |
| 6.2-R3 | Stabilisation risks are not governed | Partial | Hypercare with daily reconciliation, defect governance and formal exit criteria | 04, 08 |
Rules every load follows
These principles are commitments, not preferences. Any exception needs written approval from the accountable Amana business owner and is recorded in the migration decision log.
Nothing is dropped silently
Every source record ends up migrated, archived or rejected with a reason. Rejected records sit in an exception log until an owner decides what to do with them.
Loads go through OptimaX logic
OptimaX enforces business rules in its database procedures. Migration loads call those procedures, or a reviewed bulk path that applies the same validations, so numbering, validation and linkage rules still hold.
No automatic fixes to money
Premium, claim, commission, reinsurance and balance amounts are never changed by a cleansing rule. Any difference goes to Finance to decide.
Every record keeps its legacy identity
Each migrated record stores its legacy key, source system and migration batch ID. It can be searched in OptimaX and traced back to the source.
Rehearsed exactly as run
Extraction, transformation and load run as versioned scripts. The production run uses the same scripts that passed the final rehearsal.
Amana owns the decision at each gate
No phase moves forward until the accountable Amana owner signs its gate. Go-live requires signed reconciliation from Finance, Underwriting and Claims.
What moves, and how
Each data domain gets one migration treatment. The treatments below are the proposed baseline. Amana confirms the final treatment per domain and line of business at the Mapping & Design gate.
| Data domain | Content | Proposed treatment | Business owner |
|---|---|---|---|
| Master & reference data | Products, covers, benefit classes, branches, intermediaries and commission structures, providers, customers, chart of accounts, lookup codes | Full Cleansed and de-duplicated before any transaction load | Product / Finance |
| Tariffs & rating tables | Current and historical tariff versions, discounts and loadings with effective dates | Full Current tariffs active; historical versions loaded as closed and read-only | Underwriting / Actuarial |
| Policies & insured risks | Policies, members, insured vehicles and risks, classes, sums insured, premiums | Full All in-force policies, plus expired policies within the agreed history window | Underwriting |
| Endorsements & history | Policy- and member-level endorsements, renewals, cancellations, reinstatements | Full Chronological history kept for every migrated policy | Underwriting |
| Claims | Claim headers and lines, reserves, payments, recoveries, status history, TPA-sourced claims | Full All open claims, plus closed claims within the history window | Claims |
| Reinsurance | Treaties and facultative placements, cessions, ceded premium and commission, recoveries | Active + balances Current treaty years in full; prior years as balances with an archive link | Reinsurance / Finance |
| Financial balances | Premium receivables, claims payable, commission payable, reinsurer balances, unallocated cash | Open items Open items at item level, tied to the GL opening balances at cutover | Finance |
| Approvals & audit history | Underwriting and discount approvals, override reasons, user actions | Migrated or archived Migrated as read-only history where the source holds it in structured form; otherwise archived and linked | Risk / Compliance |
| Documents & attachments | Policy schedules, claim documents, supporting files | Linked Migrated to OptimaX document storage, or referenced from the retention archive | Operations |
| Pending quotations | Open quotations still within validity | Decision Migrate the ones valid at cutover, or re-quote in OptimaX | Underwriting |
Scope decisions Amana makes in Discovery
- History window. Full history from inception, or a defined number of years in OptimaX with older data in the retention archive (Section 10). Both options keep all data accessible. The choice changes effort and load duration.
- Cutover sequencing. A single cutover, or cutover by line of business (for example medical first, then general). Section 09 covers the coexistence rules for each option.
- Out of scope. Legacy modules replaced by other systems (for example HR, or a separate ERP general ledger) are listed and confirmed as out of scope, not assumed.
Eight phases, each closed by a signed gate
Durations are indicative and will be re-baselined once Discovery confirms Amana's systems and volumes. Amana has not yet shared those volumes, so we do not commit to a fixed calendar here. Build and mapping for different domains run in parallel wherever dependencies allow.
Mobilise
Discovery & profiling
Mapping & design
Build & unit test
Mock migrations 1–3
UAT on migrated data
Cutover & go-live
Hypercare & stabilisation
Legacy decommissioning
Source-to-target mapping and data-quality governance
Mapping Specification (Gate 2 deliverable)
A field-level document, signed per domain by the Amana business owner. For every target field it records:
| Element | What is recorded |
|---|---|
| Source | Legacy system, table, column, data type, and the filter that selects in-scope rows |
| Target | OptimaX entity, field and load procedure |
| Transformation rule | Conversion, code-value mapping (legacy code to OptimaX lookup), concatenation or split, date and currency handling |
| Default rule | Value used when the source is empty, and whether that is allowed for this field. Defaults are never allowed for financial or clinical fields. |
| Validation | Mandatory, format, range and referential checks applied before load |
| Owner & version | Approving owner, approval date and specification version, so a change after sign-off shows up |
Cleansing and exception handling
- Profiling first. Duplicates, orphans, missing mandatory fields and invalid codes are measured in Discovery and reported by domain, with counts.
- Rules approved, not improvised. Each cleansing rule is written down, approved by the owner and applied by script, so it produces the same result in every rehearsal.
- Fix at source where possible. Where a correction belongs in the legacy system (for example a duplicate customer), Amana operations correct it there before the final extraction. The migration does not hide the problem.
- Exception log. Every rejected or held record is logged with its reason, owner and decision (fix, migrate as-is, archive only). The log is part of the go-live evidence pack.
- Bilingual data. Arabic and English names and addresses are carried as Unicode end to end. After each mock migration, a character-level comparison on sampled records checks that no Arabic text was corrupted during conversion.
Legacy-to-OptimaX cross-reference
A permanent cross-reference table links each legacy key (policy, member, claim, endorsement, customer, intermediary) to its OptimaX key. It is kept after go-live. Users can search OptimaX by the legacy policy or claim number. Finance, Audit and regulators can trace any migrated balance back to the legacy source.
Four levels of proof that the data arrived intact
Reconciliation runs automatically at the end of every mock migration and the production load, and produces a signed report. Level 3 answers risk 4.1-R2 directly: migrated financial balances must agree with the legacy sub-ledgers and the General Ledger before go-live is approved.
Record counts
Source rows extracted = rows loaded + rows rejected + rows archived, per entity, per line of business.
Tolerance: 0Value totals
Control totals of sums insured, written premium, claims paid, outstanding reserves and recoveries, by product, underwriting year and branch.
Tolerance: 0 · explainedFinancial balances
Open receivables, claims payable, commission payable and reinsurer balances reconciled to the legacy sub-ledgers and the GL Trial Balance at the cutover date.
Tolerance: 0 · Finance signsBusiness verification
A sample of policies and claims per product is compared field by field, with a screen-to-screen check by business users.
Sample agreed at Gate 2| Control check | Compared | Performed by | Signed by |
|---|---|---|---|
| Policy & member population | Counts of in-force policies, members and insured risks by product and status | Migration team | Underwriting |
| Written & earned premium | Premium totals by product and underwriting year; unearned premium at cutover | Migration team | Finance / Actuarial |
| Claims population & reserves | Open and closed claim counts; outstanding reserve and paid-to-date totals | Migration team | Claims / Actuarial |
| Premium receivables | Open items by customer and intermediary against the legacy receivables ledger and GL control account | Migration team + Finance | Finance |
| Claims & commission payables | Open payable items against the legacy ledger and GL control accounts | Migration team + Finance | Finance |
| Reinsurance balances | Ceded premium, commission, recoveries receivable and reinsurer balances by treaty | Migration team + Reinsurance | Reinsurance / Finance |
| GL opening position | Opening Trial Balance in OptimaX against the legacy closing Trial Balance at cutover | Finance | CFO or delegate |
Legacy policies stay administrable on their original terms
Risk 4.1-R3 is that migrated policies lose the tariff, terms and approvals they were written on. Risk 1.6-R2 is that endorsements on them get priced on the wrong basis. The design below addresses both.
| Element | Treatment | Verified by |
|---|---|---|
| Historical tariff versions | Every tariff version referenced by a migrated in-force policy is loaded into OptimaX with its original effective dates, then closed so it cannot be selected for new business or edited | Tariff count and rate comparison against legacy |
| Policy-to-tariff link | Each migrated policy stores a reference to the tariff version it was priced on | Level 4 sample |
| Premium as charged | Migrated premiums, discounts and loadings are loaded exactly as charged and are never recalculated by OptimaX | Level 2 value totals |
| Re-rating check | As a separate test, a sample of migrated policies is re-rated on its historical tariff. Differences point to tariff configuration errors and are investigated. The migrated premium is not changed. | Actuarial review in Mock 2 and Mock 3 |
| Endorsements on legacy policies | Pricing basis for mid-term changes on migrated policies (original tariff, or current tariff pro rata) is set per product by Underwriting at Gate 2 and configured as a rule | Named UAT scenarios per product |
| Transaction history | Endorsements, renewals, cancellations and claim status history are migrated in date order with their original dates and references | Level 1 counts and Level 4 sample |
| Approvals & overrides | Structured approvals (approver, date, amount, reason) are migrated as read-only history. Unstructured evidence is archived and linked to the policy. | Risk / Compliance sample review |
Three mock migrations, then a controlled cutover
| Rehearsal | Purpose | Pass criteria |
|---|---|---|
| Mock 1 · Technical | Full-volume run of every script end to end; exposes data-quality issues and runtime | All domains load; exception log produced; runtime measured |
| Mock 2 · Reconciliation | Full volume with approved cleansing rules; first full reconciliation pack reviewed by Finance and business owners | Level 1–3 differences all explained; exception volume within the agreed threshold |
| Mock 3 · Dress rehearsal | Timed exactly as cutover, with the production runbook, the same scripts and the same team; includes a rollback exercise | All tolerances met; completes inside the cutover window; rollback shown to work |
Go/no-go criteria (Gate 6)
- Production reconciliation Levels 1–3 within tolerance, signed by Finance, Underwriting and Claims
- No open P1 or P2 migration defects; any P3 items accepted in writing with an owner and due date
- User access for go-live provisioned and reviewed against the approved role matrix
- Interfaces (TPA, aggregators, regulatory, GL) switched and a first transaction confirmed on each
- Support rota, hypercare channel and business contingency procedures in place
Rollback
Legacy stays intact and frozen throughout cutover. The runbook sets a point of no return: the moment after which new business transactions are entered in OptimaX. Before that point, rollback means reopening legacy with no data loss. After it, open issues are fixed forward in OptimaX under hypercare, and any transaction that has to be re-entered is logged and reconciled. The rollback triggers and the people who can call a rollback are named in the runbook.
How legacy and OptimaX run side by side
From go-live, OptimaX is the single system of record for new transactions. Legacy is not used to process business in parallel, which would create two conflicting sources of truth (risk 2.2-R2). It stays available read-only for enquiry, audit and reconciliation until decommissioning.
Coexistence rules
| Situation | Rule |
|---|---|
| Freeze window | Legacy transaction entry stops at a published time. Urgent cover during the window is issued under a documented contingency procedure and entered in OptimaX after go-live. |
| In-flight transactions | Open claims, pending endorsements and unpaid items migrate in their current status and are completed in OptimaX. No transaction is split between the two systems. |
| Phased cutover by line of business | If chosen, each line has its own freeze and go-live. Shared masters (customers, intermediaries, chart of accounts) are owned by OptimaX from the first cutover and synchronised to legacy in one direction only until the last line moves. |
| Interfaces | Each interface (TPA, aggregators, regulatory submissions, General Ledger) gets a switch-over date. Record-count and value checks run daily during hypercare to catch anything still routed to legacy. |
| Legacy access after go-live | Enquiry roles only, for named users approved by their department head. Access is logged, and the list is reviewed monthly by IT Security. |
| Late legacy corrections | No corrections are made in legacy after go-live. Any correction is posted in OptimaX and referenced to the legacy record. |
Legacy is retired only when nothing depends on it
Amana Compliance sets the retention period for each data domain, based on Insurance Authority, legal and tax requirements. The migration design meets that period through two routes:
- In OptimaX: data inside the agreed history window, fully searchable and reportable.
- In a retention archive: older history and anything not migrated, held in a read-only, access-controlled database with enquiry screens and standard extracts. The archive is restore-tested, and its contents are reconciled to legacy before legacy is retired.
Decommissioning checklist (Gate 8)
| # | Condition | Evidence | Signed by |
|---|---|---|---|
| 1 | Hypercare closed and at least one quarter-end closed on OptimaX | Hypercare exit report, quarter-end reconciliation | Finance |
| 2 | All migration exceptions resolved or formally accepted | Closed exception log | Business owners |
| 3 | Retention archive complete and reconciled to legacy | Archive reconciliation report | IT / Compliance |
| 4 | Archive restore and retrieval tested | Restore test record, sample retrieval by business users | IT |
| 5 | Historical regulatory and audit reports can be reproduced from OptimaX or the archive | Reproduced report samples | Compliance / Internal Audit |
| 6 | No open audit, legal or regulatory request needs the live legacy system | Confirmation from Legal and Compliance | Compliance |
| 7 | Final full backup of legacy taken and stored under the retention policy | Backup record | IT |
| 8 | All legacy user access removed and licences terminated | Access removal report | IT Security |
Protecting the data while it moves
Confidential and medical data
Extracts move over encrypted channels only. Non-production copies are masked for personal and medical fields unless Amana approves unmasked data for a specific test.
Named, logged access
Only named migration-team members can reach source extracts and staging. Access is logged and removed at hypercare exit.
Segregation of duties
The migration team cannot approve its own exceptions or reconciliation differences. Those decisions belong to Amana owners.
Change control on scripts
Scripts and the Mapping Specification are version-controlled. Any change after Mock 3 needs a documented re-test and owner approval.
Batch audit trail
Every load records its batch ID, script version, operator, start and end time, and row counts. Migrated records carry the batch ID.
No direct production edits
After go-live, migrated data is corrected only through normal OptimaX transactions with their audit trail, never by direct database update.
Migration-specific risks and their controls
| # | Risk | Rating | Mitigation | Owner |
|---|---|---|---|---|
| M1 | Legacy data quality (duplicates, orphans, blank mandatory fields) is worse than expected | High | Profiling in Discovery before estimates are fixed; approved cleansing rules; fix at source; exception log | Migration Lead / Business owners |
| M2 | Financial balances do not tie to the GL at cutover | High | Level 3 reconciliation from Mock 2 onward; Finance involved from Gate 2; month-end aligned cutover date | Finance |
| M3 | Undocumented legacy logic (codes, derived fields) is misread | Medium | Sessions with legacy system experts and the legacy vendor where needed; Level 4 field-by-field sample | Migration Lead |
| M4 | Load runtime exceeds the cutover window | Medium | Runtime measured in Mock 1; tuning before Mock 3; pre-load of closed history before the freeze | Migration Lead |
| M5 | Historical tariffs incomplete in legacy | Medium | Tariff inventory in Discovery; missing versions rebuilt from Actuarial records and approved; premium never recalculated | Actuarial / Underwriting |
| M6 | Business disruption during cutover | Medium | Weekend window, contingency procedures, dress rehearsal, tested rollback | Programme Steering |
| M7 | Delayed access to legacy systems or legacy vendor support | Low–Med | Access confirmed at Gate 0; Amana sponsors legacy vendor engagement; buffer in Discovery | Amana IT |
| M8 | Arabic text corrupted during conversion | Low–Med | Unicode end to end; character-level comparison on samples each mock | Migration Lead |
| M9 | Legacy retired before retention or audit needs are met | Low | Eight-condition decommissioning checklist; multi-function certificate | Compliance |
Who does the work, who decides
The Toshfa OptimaX implementation team carries out the technical migration: profiling, mapping, build, load, reconciliation reports and cutover. Amana provides database connectivity to its legacy systems, business decisions, UAT and sign-off at each gate.
| Activity | Toshfa Migration Team | Amana Business Owners | Amana Finance | Amana IT | Amana Risk & Compliance |
|---|---|---|---|---|---|
| Legacy connectivity & access | C | I | I | R/A | I |
| Discovery & profiling | R/A | C | C | C | I |
| Scope & history-window decisions | C | A | C | I | C |
| Mapping Specification | R | A | C | I | I |
| Cleansing rules & exceptions | R | A | C | I | I |
| Build, load, mock migrations | R/A | I | I | C | I |
| Financial reconciliation sign-off | R | C | A | I | I |
| UAT on migrated data | C | R/A | R | I | I |
| Go/no-go decision | C | A | C | C | C |
| Cutover execution | R/A | C | C | R | I |
| Retention archive & decommissioning | R | C | C | A | C |
R Responsible · A Accountable · C Consulted · I Informed. Amana Risk & Compliance can attend any gate review and receives every gate's evidence pack.
What Amana receives, and when
These documents make up the migration evidence trail. Amana Risk can test each one before the next gate opens.
| Deliverable | Content | Gate |
|---|---|---|
| Migration & Coexistence Strategy | This document | Now |
| Data Profiling Report | Legacy inventory, volumes, data-quality findings, re-baselined plan | Gate 1 |
| Mapping Specification | Field-level mapping, transformation, cleansing and default rules, signed per domain | Gate 2 |
| Reconciliation Design | Control checks, totals, tolerances, samples and sign-off owners | Gate 2 |
| Mock Migration Reports (×3) | Runtime, exception log, Level 1–4 reconciliation results per mock | Gate 4 |
| Cutover Runbook & Rollback Plan | Step-by-step timeline, freeze, point of no return, rollback triggers and authority | Gate 4 |
| UAT Sign-off | Scenarios on migrated data, including legacy-tariff endorsements; defect status | Gate 5 |
| Production Reconciliation Pack & Go/No-Go | Signed reconciliation and go/no-go record | Gate 6 |
| Hypercare Exit Report | Defects, daily reconciliation trend, first month-end result | Gate 7 |
| Decommissioning Certificate | Eight-condition checklist with evidence and signatures | Gate 8 |
What we need from Amana to finalise the plan
| # | Item | Needed from | Needed by |
|---|---|---|---|
| 1 | Legacy system inventory: products, databases, versions, and which lines of business each one holds | Amana IT | Gate 0 |
| 2 | Read access to legacy databases (or agreed extracts) for profiling | Amana IT | Gate 0 |
| 3 | Approximate volumes: policies, members/risks, endorsements, claims, years of history | Amana IT | Gate 1 |
| 4 | Retention periods per data domain | Amana Compliance | Gate 1 |
| 5 | History-window decision, and single or phased cutover | Amana Business Owners | Gate 1 |
| 6 | Named business owner per data domain | Amana Programme Sponsor | Gate 0 |
| 7 | Target cutover date, aligned to a month-end or quarter-end | Amana Finance | Gate 1 |