Salama to Toshfa OptimaX
Data Migration Plan
Scope, source-to-target mapping, phased approach, effort estimate and risk register for migrating the Client's medical-insurance data from its legacy core system and associated schemas into Toshfa OptimaX.
Three source systems, one migration decision to make first
The Client's medical-insurance business runs today on Al-Makhnah (internally called the Jamal system), an Oracle-based core holding underwriting and claims history in its SLM schema. Two further data sources sit alongside it: Globemed, a claims-enrichment staging schema that is being populated daily but is not actually used operationally, and a standalone SQL Server database for Tourist / Visit Visa quotations. Moving to OptimaX means migrating all three — and they differ sharply in volume, maturity, and data quality.
This document sets out what is in scope, how each source maps onto OptimaX, a phased migration approach, a rough-order-of-magnitude (ROM) effort and timeline estimate, and the risk register that should be reviewed before resourcing is committed. To fit an 8-week (2-month) go-live window, the plan runs three build workstreams fully in parallel on a larger team and bounds the Globemed enrichment brought across at cutover — see the compression trade-offs called out below and in Section 05.
Migration execution is entirely owned by the Toshfa OptimaX implementation team. The Client is not resourcing or performing any part of the technical migration — its role is limited to opening database connectivity to the existing Oracle (SLM, Globemed) and SQL Server (Visit Visa) systems, plus the business approvals and UAT laid out in Section 09.
Current state — three systems, three purposes
Al-Makhnah is the operational system of record. Globemed is a TPA-fed enrichment schema that never made it into daily use. Visit Visa is a satellite quotation system that feeds Al-Makhnah once a quote converts. Each has a different implication for the migration.
Al-Makhnah / Jamal
Oracle · SLMThe live medical-insurance core: underwriting (policies, endorsements, members) and claims, from inception. This is the primary source for the OptimaX Policy, Endorsement, Member and Claim modules.
Globemed
Oracle · StagingA staging schema Globemed (the TPA) pushes daily claims data into. Al-Makhnah only captures finance/account-level claim data — service-level detail exists nowhere else. In practice the daily push is not consulted: claims staff still reconcile a daily Excel export manually.
Visit Visa
SQL ServerA separate database for Tourist / Visit Visa quotations. Once a quote converts, it is written into Al-Makhnah/SLM as a policy — so this database is quotation-only.
| Schema | Table | Row Count | Notes |
|---|---|---|---|
| SLM | Policies | 1,000,000 | Primary UW record |
| SLM | Policy Endorsement | 1,500,000 | Policy-level endorsement history |
| SLM | Policy Member | 3,800,000 | Member-level UW record |
| SLM | Member Endorsements | 4,200,000 | Member-level endorsement history |
| SLM | PolicyClass | 1,300,000 | Benefit / class configuration |
| SLM | Claim Batches | 100,000 | Claim intake batch grouping |
| SLM | Claim Header | 3,200,000 | Primary claim record |
| SLM | Claim Detail | 9,500,000 | Finance/account-level claim lines |
| Globemed | CLAIMS_INTEG_HEADER | 40,000 | Daily TPA claim push — header |
| Globemed | CLAIMS_INTEG_DETAILS | 100,000,000 | Service-level breakdown — not in operational use today |
| Visit Visa | Quotations | TBD | Pending schema access / profiling |
What moves, what doesn't, and what's still an open call
The scope below reflects the data confirmed to date. Three items are marked "open" because they change the effort and timeline materially and need a business decision, not a technical one.
In Scope
- Full SLM underwriting set: Policies, Policy Endorsements, Policy Members, Member Endorsements, Policy Classes
- Full SLM claims set: Claim Batches, Claim Headers, Claim Details
- Globemed service-level enrichment, matched and merged into the corresponding OptimaX claim
- Active Visit Visa quotations (within the 3-month validity window at cutover)
Out of Scope (proposed)
- Globemed staging rows with no matching SLM claim header, unless a business owner asks for them to be preserved
- Expired Visit Visa quotations that never converted to a policy
- Al-Makhnah modules outside the SLM UW/claims tables named in this document (e.g. finance/GL, HR)
Open Scope Decisions
- Historical cutoff — full 24.6M-row SLM history from inception, or a bounded window with older records archived?
- Visit Visa mode — bulk-migrate active quotations at cutover, or fetch-on-demand integration?
Legacy source → OptimaX target
OptimaX is stored-procedure-first (~470 SPME_* procedures enforce business rules on write). Migration load logic must call the correct procedures rather than write to tables directly, so existing validations, numbering rules and workflow triggers stay intact.
| Legacy Source | Volume | OptimaX Target | Migration Note |
|---|---|---|---|
| SLM.Policies | 1.0M | Policy | Segment (Individual/SME/Corporate) derived from SLM policy attributes |
| SLM.Policy Endorsement | 1.5M | Endorsement | Maps onto OptimaX's endorsement transaction types (addition, deletion, upgrade, downgrade, correction…) |
| SLM.Policy Member | 3.8M | Policy Member | Linked to parent Policy via converted policy key |
| SLM.Member Endorsements | 4.2M | Member Endorsement | Member-level endorsement history |
| SLM.PolicyClass | 1.3M | Policy Class / Benefit | Benefit & class configuration per policy |
| SLM.Claim Batches | 100K | Claim Batch | Claim intake batch grouping |
| SLM.Claim Header | 3.2M | Claim Header | Primary claim record — also the matching key for Globemed enrichment |
| SLM.Claim Detail | 9.5M | Claim Line | Existing finance/account-level granularity |
| Globemed.CLAIMS_INTEG_* | 100.0M | Claim Line (enrichment) | Merges service-level breakdown into the matching OptimaX claim; unmatched rows routed to an exception queue |
| Visit Visa.Quotation | TBD | Quotation | Tourist/Visit Visa segment; already-converted quotations excluded (present as SLM-sourced Policies) |
8 weeks to go-live, on a wider parallel team
Fitting this into 8 weeks means changing the levers, not just the labels: a focused ~4–5 person team, fully dedicated to this migration rather than split across other work, runs Discovery, Mapping and all three ETL builds concurrently from Week 1; validation compresses to one full mock-migration cycle plus a focused performance pass instead of two independent cycles; and Globemed enrichment at cutover is bounded to a recent window rather than its full history.
Everything left of the Go-Live line below is on the critical path to Week 8. Everything right of it — hypercare and the full Globemed historical backfill — runs after the business is already live on OptimaX, so it doesn't gate the 8-week date.
47 person-weeks to go-live, on a 4–5 person team
Hitting an 8-week calendar date with this volume of data means a focused, fully-dedicated team rather than a schedule stretched over more time: plan for roughly 4–5 people on the Toshfa OptimaX implementation team (1–2 data/ETL analysts, 2 ETL developers, 1 DBA/QA-reconciliation analyst, with the migration lead doubling as PM) running Discovery, mapping and all three ETL builds concurrently — entirely vendor-side effort; see Section 09 for the Client's (non-execution) role. Figures exclude Visit Visa contingency, which will be re-baselined once its volumetrics are confirmed in Discovery.
| Workstream | Person-Weeks | Key Activities |
|---|---|---|
| Discovery & Data Profiling | 3 | Oracle SLM/Globemed & Visit Visa SQL profiling; key/relationship discovery; Globemed↔SLM matching-key validation — run by 3 analysts in parallel, Week 1 |
| Mapping & Design | 4 | Field/SP mapping against ~470 SPME_ procedures; cleansing rules; reconciliation key design |
| ETL Build — SLM Core | 9 | Policies, Endorsements, Members, Member Endorsements, PolicyClass, Claim Batches/Header/Detail |
| ETL Build — Globemed Enrichment (bounded window) | 6 | Batched/parallel extraction, scoped to a recent window (proposed 12–24 months) for go-live; full history moves to Phase 2 below |
| ETL Build — Visit Visa | 3 | Active-quotation extraction; conversion-linkage check against SLM to avoid duplicates |
| Data Cleansing & Exceptions | 3 | Business-rule fixes; orphan/duplicate resolution; exception sign-off loop — rolling, overlaps build |
| Mock Migration & Reconciliation (single cycle) | 5 | One full dry-run load with count/sum/financial reconciliation, plus a focused performance pass |
| UAT Support | 2 | Business validation with Claims & Underwriting, run alongside the performance pass |
| Cutover Planning & Go-Live | 2 | Rehearsal, freeze window, go/no-go, rollback plan |
| PM & Governance | 10 | Runs throughout Weeks 1–8 — steering, RAID log, vendor coordination |
| Subtotal — to Go-Live (Wk 1–8) | 47 | ROM — pre-Discovery baseline |
| Hypercare (post go-live) | 4 | Post go-live monitoring and defect triage, Weeks 9–12 |
| Globemed Full-History Backfill (post go-live) | 6 | Remaining historical detail loaded once the core system is live, Weeks 9–14 |
| Total — incl. post go-live | 57 | ROM — pre-Discovery baseline |
12 risks tracked, 3 currently critical
Two of the three critical risks trace back to the same fact: Globemed has never been operationally relied upon, so neither its match quality against SLM claims nor its load performance has ever been proven in practice. The third is new in this revision — compressing to an 8-week go-live inherently raises residual-defect risk, since cleansing, mock-migration and UAT cycles now run once instead of twice.
| # | Risk | Severity | Mitigation |
|---|---|---|---|
| R1 | Globemed matching keys to SLM claims are unverified — the schema has no live reconciliation process to have proven them. | Critical | Joint working session with Globemed/TPA and Finance in Discovery to define and validate matching keys; build an orphan/exception report; business sign-off on any claims that can't be auto-matched. |
| R2 | 100M-row Globemed detail table risks ETL runtime, source-DB load and OptimaX write-throughput overruns. | Critical | Batched/throttled extraction in off-peak windows; staged bulk-load ahead of SP processing; go-live scope bounded to a recent window (Section 03) with full history backfilled post go-live. |
| R12 | Compressing to an 8-week go-live leaves only a single mock-migration, cleansing and UAT pass — less room to catch defects than a longer timeline would give. | Critical | Bound go-live scope (SLM core + active Visit Visa + recent Globemed window) so the single validation pass covers less data; keep the 4–5 person team fully dedicated to this migration rather than cutting further steps; keep hypercare and the historical backfill as an explicit post-go-live safety net rather than compressing them into Week 8 too. |
| R5 | Legacy data-quality issues (duplicate members, orphaned endorsements, blank mandatory fields) from an 18+ year-old core. | Serious | Profiling-led cleansing rules agreed with business owners; named-approver exception queue; no silent auto-fix of financial/clinical fields. |
| R7 | OptimaX's SP-first architecture means load logic must respect existing business rules, not copy tables directly. | Serious | Migration team pairs with OptimaX engineering to identify the correct SPME_ entry point per entity; any migration-only bulk path reviewed by the product owner. |
| R8 | Dependency on Jamal (legacy vendor) and Globemed (TPA) for timely extract access. | Serious | Formal data-extract SLA agreed pre-kickoff; the Client sponsors/escalates vendor engagement; buffer built into the Discovery phase. |
| R10 | Business disruption at cutover — claims processing cannot simply pause. | Serious | Parallel-run window with a defined freeze, tested rollback plan, low-activity cutover scheduling, go/no-go criteria with business sign-off. |
| R11 | Historical cutoff for SLM data is undefined — how far back to migrate vs. archive. | Serious | Confirm retention policy with Client management during Discovery; document as a formal scope decision, not an assumption. |
| R3 | Visit Visa quotations already converted to SLM policies could be re-migrated as duplicates if linkage detection misses them. | Warning | Reconciliation step comparing Visit Visa quotation IDs against SLM policy source references before load; exclude/flag converted quotations. |
| R4 | Visit Visa volumetrics are unknown — sizing and effort for this stream aren't yet confirmed. | Warning | Prioritize Visit Visa schema profiling in Discovery Week 1; re-baseline effort/timeline once volumes are known. |
| R6 | Oracle→SQL Server conversion risk: datatype, character set (bilingual Arabic/English fields), date/numeric precision. | Warning | Early technical spike on a representative sample per table; conversion rulebook signed off before full build. |
| R9 | PHI/financial data sensitivity in transit and in non-production environments. | Warning | Encrypted transfer channel; masked/de-identified data in non-prod; access limited to named migration-team members and logged. |
What this plan is relying on
- 01The Client's only technical contribution is database connectivity — read access/credentials to the Oracle SLM & Globemed schemas and the Visit Visa SQL Server instance. All profiling, extraction, transformation and load work is performed by the Toshfa OptimaX implementation team.
- 02Visit Visa SQL Server connection details, schema, and volumetrics are provided in Discovery Week 1.
- 03OptimaX's SPME_ procedures support all required entity loads; any gap found is raised as a product change request, tracked separately from migration effort.
- 04The Client confirms the SLM historical-retention cutoff, and the Globemed and Visit Visa scope decisions, by the end of Discovery.
- 05A non-production migration environment sized for 100M+ row test loads is provisioned ahead of ETL build.
- 06Where Globemed (TPA) or Jamal (legacy vendor) need to be involved beyond the database connection itself — e.g. clarifying an undocumented field — the Client facilitates that access; the migration team does not need a direct commercial relationship with either.
- 07Effort and timeline figures in this document are ROM estimates based on volumetrics known today; they will be re-baselined after Discovery & profiling.
- 08A ~4–5 person team is resourced, fully dedicated to this migration, and available from Week 1 — the 8-week date depends on focused parallel effort, not schedule compression alone.
- 09The Client accepts a phased go-live: full SLM core plus a bounded recent Globemed window at Week 8, with the remaining Globemed history backfilled in the following weeks without disrupting live operations.
RACI across the program
Migration execution is fully owned by the Toshfa OptimaX implementation team. The Client's only technical contribution is opening database connectivity to its existing Oracle (SLM, Globemed) and SQL Server (Visit Visa) systems — its remaining involvement is business approvals and UAT, not migration work itself.
| Activity | Client Business | Client IT | Migration PM | Data Team | OptimaX Eng. | Jamal | Globemed |
|---|---|---|---|---|---|---|---|
| Database Connectivity & Access | I | R | A | C | I | I | I |
| Data Profiling & Discovery | I | C | A | R | C | C | C |
| Mapping & Design Sign-off | A | I | R | R | C | I | I |
| ETL Build | I | I | A | R | C | I | I |
| Cleansing Rule Decisions | A | I | R | R | C | I | I |
| Mock Migration & Reconciliation | C | I | A | R | R | I | I |
| Performance Testing | I | C | A | R | R | I | I |
| UAT | R | I | A | C | C | I | I |
| Go/No-Go Decision | A | I | R | C | C | I | I |
| Cutover Execution | C | C | A | R | R | I | I |
| Hypercare Support | C | C | A | R | R | C | C |
What "done" means for this migration
- 100% record-count reconciliation between source and target across all in-scope tables
- Financial reconciliation of claim amounts within an agreed tolerance
- Zero unresolved Priority-1 defects at go-live
- UAT sign-off from both Claims and Underwriting departments
- Rollback plan tested and approved before cutover
- Hypercare period closed with no open Sev-1/Sev-2 issues
- Full Globemed historical backfill completed and reconciled within the post-go-live window, without disrupting live operations