Merit · E-Commerce Solution · Al Fursan (Saudia)
We know where we are going. We do not yet know what we are carrying. This is the plan to find out, build it, and cut over by the end of October, with a real go/no-go on 12 September.
We cannot list what to build in the Ecommerce Solution, because nobody holds a full picture of what the legacy system does today.
The repo holds a parity list: 14 P0 gaps in the Q3 2026 Ecommerce Solution Plan. That list is real and useful. It is also not the parity list, and treating it as one is the single largest risk in this migration.
Those 14 gaps were derived from what Marketplace and Platform shipped in Q2 2026. They are a one-quarter delta. Everything the legacy system gained before April 2026 is absent.
A mechanical comparison ran against both Jira instances on 24 August, epic by epic, before discovery started. It does not settle the question, and it does move it.
Nothing on our boards covers them at all.
MP: catalog selection and approval MP-11621 · fulfilment cooling period MP-11685 · earn model, cashback in miles MP-11785/86 · promotions engine phase 1 MP-12016 · data-driven ordering phases 1 and 2 MP-11568 MP-11841 · bulk order placement MP-12070
MPS: payouts MPS-17 · points exchange MPS-299 · online catalog MPS-483 · API client onboarding MPS-154 · Giftcardsby MPS-137 · RewardsBy MPS-261
Exist on both sides, narrower or unfinished.
Five bespoke storefronts collapse into STOR-1 Tenant Provisioning, still To Do · search MP-11888 to MSP-175 · product import MP-9603 to MSP-118 · MGC fulfilment MP-11581 to MSP-176 · SMS and email to MSP-48 · merchandise and catalog to MSP-283 · Content API to STOR-4, still To Do
Webhooks. MPS-139 against MSP-27, done.
One clean match out of twenty-two compared.
14 known items, plus 13 absent, plus 8 partials that each need sizing. None of that counts capability living in stories rather than epics, and MP epics are named by client rather than by capability, so most of the surface never became an epic. The two that matter most: STOR-1 Tenant Provisioning is To Do and replaces five bespoke storefronts at once, and Points Exchange has no counterpart at all, which is the reason Al Fursan exists.
A missing epic does not prove a missing capability. It proves nobody wrote an epic. This is a starting list for discovery to confirm, not a backlog. It is enough to say the 14-item answer was never derived from the real surface, and it understates rather than overstates. Comment on it here: the first-pass gap list.
Brian on the 30 July Marketplace sprint call: it "is custom and we definitely need to build everything that the marketplace team already have into what we have." A custom frontend has no vendor documentation and no feature list.
Marketplace owns the storefront surface. Platform Services owns payments, payouts, messaging, content, partner integrations, catalog and merchandise. Ops owns the catalogue and the rules that never became code. No one person can answer the question.
Older meeting transcripts render this as "AlphaZen" or "AlphaSun", including the one that reached DEC-0066. Both are transcription errors for Al Fursan. There is no separate system by that name.
It is an inventory. Section 04 is how we produce it.
One thing for Saudia, one thing for Merit, and one rule that governs the whole build.
Same journeys, same catalogue, same points behaviour, same order history. The only change a member notices is the new design, which Raneen is producing.
This gives a clean client conversation: it is a redesign, and the platform change sits underneath it. Honest, and it lowers the approval cost.
Al Fursan stops being a bespoke build and becomes the first tenant on a multi-tenant product. The legacy system is one build per client. The Ecommerce Solution is one product serving many.
That is the moat argument: the stack compounds across tenants, a bespoke build never does.
This migration moves one client. Entertainer, Nielsen, NIQ, Kantar Verian, SAIB, MCM and Agora stay on the legacy system and stay supported there. The stack is built tenant-generic so they can follow, but no other client is in this plan and no date is implied for them.
Gift card fulfilment keeps running on the legacy system. The storefront never calls it directly: an order goes storefront to Ecommerce Core to order state management to fulfilment service, and only then triggers legacy to issue the card. Nothing in the register may propose rebuilding it. This is the meaningful cut: gift cards are the highest-volume thing Al Fursan does, and leaving that path untouched removes the largest single source of cutover risk.
Both boundaries were set before discovery, on purpose, so the lenses do not spend a week inventorying work nobody intends to do.
We rebuild the full surface. We do not measure which legacy features get used and drop the quiet ones. Everything Al Fursan does today gets built. That makes the build larger and the sequencing question sharper, and section 08 answers it: everything is built, but not all of it before cutover.
One date governs this migration. Every other date is a step toward it, not a second target.
From 24 August to the end of October is 9.7 weeks. It divides three ways, and the split holds before we know anything else.
■ discovery, 2 weeks ■ build, ~5 weeks ■ dual run and cutover, 2 weeks
No capability inventory exists, so the parity build has nothing to build from. That is why discovery takes the first two weeks rather than running alongside the build.
The team, Fred and Saudia hear end of October and nothing else. Carrying two dates at once is how the Al Fursan BRD ended up with two versions of v2.1.
Reading documents will not produce it, because the documents were never written. Three independent lenses, run in parallel, then reconciled. Each finds what the others miss.
Walk the storefront routes and the Marketplace backend endpoints. Every screen, every API, every admin action.
Inventory every Platform service Al Fursan calls: payments, payouts, messaging, content, partner integrations, catalog, merchandise.
Walk the Ops runbook: catalogue rules, supplier coverage, approval flows, merchandise handling, the manual steps that never became code.
Ops rules that were never coded do not appear in lens A or lens B. They surface at cutover, as an incident.
One row per capability. No row leaves the register without every column filled.
| Column | Why it is there |
|---|---|
| Capability | The thing Al Fursan does today |
| Legacy owner | Marketplace, Platform, or Ops |
| Where it lives | Storefront route, Platform service, or manual process |
| Ecommerce Solution status | Exists, partial, or absent |
| Verdict | Rebuild or integrate. Every row gets one |
| Wave | Cutover, or post-cutover |
| Size and owner | Required on every row |
Because we build the whole surface, the register does not decide what gets built. It decides when. Every row is either in the cutover wave or the post-cutover wave, and every post-cutover row carries a named owner and a November date. That is what stops "later" from meaning "never".
Everything before the go/no-go is fixed. Everything after it depends on what the register says.
| # | Step | Owner | By |
|---|---|---|---|
| 0.1 | Kick-off with the working group. Confirm the approach, the two scope boundaries, and the Project Manager seat. Each member pulls in who they need and hands down what they own | Brian · Fayez Abu Helow · Mohammad Albadarneh · Mawi · Ghaith Fakhouri · Raneen Abdelfattah · Ammar AlSadeq | Mon 24 Aug, 12:00 Amman |
| 0.2 | Confirm to Fred in writing what starts now, who is on it, the boundaries, and the honest date. Discussed offline already | Brian to Fred Barry | Mon 24 Aug |
| 0.3 | Record the end-of-October commitment in the decision log | Brian | Same day |
| 0.4 | Name one accountable engineering lead. The Project Manager seat is filled, the engineering seat is not | Fred Barry | Tue 25 Aug |
Fred is asked to sponsor a plan the working group has already agreed, not a plan he has to arbitrate. The four in the room are the ones who carry it: technology direction, project management, and the two Ops seats whose rules never became code.
Day 1 of the workshop closed with 84 of 106 epics unassigned. A migration with no named engineering lead inherits exactly that. The Project Manager covers coordination, not engineering accountability, and the two are not the same seat.
| # | Step | Owner | By |
|---|---|---|---|
| 1.1 | Kick-off with Marketplace. Scope lens A, agree the route walk | Brian, Aditya Sanka | Wed 27 Aug |
| 1.2 | Kick-off with Platform. Scope lens B, get the service call list | Brian, Akshay Chennupati | Wed 27 Aug |
| 1.3 | How the Ecommerce Solution connects to everything around it, and which Platform services stay after cutover | Brian, Muneeb Meer | Thu 28 Aug |
| 1.4 | Ops session. Scope lens C, the catalogue and merchandise rules | Brian, Mawi, Raneem Ajana | Thu 28 Aug |
| 1.5 | Data session. Open the data continuity workstream | Brian, Marthino Yuda | Fri 29 Aug |
| 1.6 | Three lenses run, chased daily | Lens owners, tracked by Albadarneh | Fri 5 Sep |
| 1.7 | Reconcile into one Capability Register | Brian, Mohammad Albadarneh | Fri 5 Sep |
| # | Step | Owner | By |
|---|---|---|---|
| 2.1 | Every row in the register gets an engineering estimate | Engineering lead, coordinated by Albadarneh | Wed 10 Sep |
| 2.2 | Compare the cutover-wave estimate against the weeks left | Brian | Thu 11 Sep |
| 2.3 | Split into cutover wave and post-cutover wave. Every post-cutover row gets an owner and a November date | Brian, Mohammad Albadarneh | Thu 11 Sep |
| 2.4 | GO / NO-GO on the October cutover | Fred Barry | Fri 12 Sep |
Brian's own words: we do not yet have enough plan. This is the date we find out. A no-go on 12 September still leaves seven weeks to build a different answer, instead of discovering the problem in the last week of October.
Four parallel tracks. Contents come from the register, so they cannot be listed yet. The tracks and owners can.
Storefront build on Raneen's new design, covering the legacy storefront surface.
Storefront team, design from Raneen
The rebuild rows. The 14 P0 gaps plus the 13 absent and 8 partial epics the Jira comparison found, extended by whatever discovery adds.
Engineering lead, delivery tracked by Albadarneh
The Platform service calls. Payments, payouts, messaging, partner integrations, redemption.
Akshay Chennupati, Muneeb Meer
Every product live on the legacy system exists in the Ecommerce Solution, with correct suppliers and rules.
Mawi, Raneem Ajana, PIM team
A storefront with no products is not a migration. Section 07 covers the data half of it.
The new system runs alongside the legacy system and mirrors every order and every data change, while the legacy system keeps doing the real processing. Nothing customer-facing depends on the new system until its output matches. When it does, legacy goes off and the new world goes on, in one move.
| # | Step | By |
|---|---|---|
| 4.1 | Shadow run starts. Both live, all data and processing mirrored, legacy still authoritative | Mon 20 Oct |
| 4.2 | Compare output continuously. Orders, settlement, points and fulfilment must match with zero unexplained differences | 20 to 23 Oct |
| 4.3 | Go / no-go on switchover | Fri 24 Oct |
| 4.4 | Switchover. Legacy off, new world on, in one move | Mon 27 Oct |
| 4.5 | Legacy warm as rollback, no traffic | 27 to 31 Oct |
Shadow output matches legacy exactly across orders, settlement and points · zero P0 failures during the shadow window · rollback tested and timed · Saudia has signed off on the new design.
It proves the new system computes the same answers. It does not prove Ops can run it, and it does not prove Crystal can answer a customer question on it. Those are the next two sections.
Surfaced in the 24 August session. They appear on neither side's Jira, which is the clearest evidence the boards understate the work.
Crystal, the third-party support team in Jordan that Merit manages, looks orders up by order ID or customer ID. They cannot be handed Merit-internal tooling, so the lookup has to live in the Saudia admin dashboard on the new world.
Ammar scopes it, after asking Raneem Ajana what Crystal uses today.
The Portal supports individual and bulk upload but not API. It was started and never finished. Migrating every active Al Fursan supplier depends on it.
Sellers integrate with our API, not the reverse. Custom integration only for a seller with the bargaining power to require it.
WhatsApp notification runs through Saudia's Accenture system, which has no team behind it. It moves to Marthino's platform, and which integrations move has never been identified.
Marthino Yuda.
The legacy system has no location awareness, because it was built for gift cards. The new system is warehouse-location aware, which matches how STC's city-level stock works. Manual fulfilment covers the gap until the new-world integration lands, and STC does not block the migration.
The gap list marks cashback in miles as absent. That is right for the Ecommerce Solution, and the reason matters more than the status.
Configured on the demo environment, configurable per product by an admin with no engineering. Roughly ten minutes to apply. Apple products today, and widening it is an admin change.
So this is a rebuild of something already working, not a design problem. That makes it cheaper than the gap list implies and it does not make it optional.
Merit is waiting on the cashback funding percentage. Hamza Shahbaz took the Merit and Saudia funding split to Julia and Justin at Saudia, and the decision sits with them. Thamer is still waiting.
It needs a number from a client's finance function. Chase it on that basis, rather than tracking it as a build.
Owner: Marthino Yuda. It does not fail like a feature fails. A missing feature is visible on day one. Broken data continuity is invisible until a member opens their order history, or until Finance closes the month.
A member sees an empty account. This is the most visible possible failure to Saudia.
Including accruals in flight. Money. Any difference is a member complaint and a client escalation.
Metabase and the Ops dashboards keep working across the boundary. Otherwise Ops and Finance lose their numbers in the same week the platform changes.
An order placed on the legacy system and delivered after cutover must still resolve, refund and settle. This is a rule about which stack owns an order that spans the boundary, decided before the dual run, not during it.
DEC-0018 settled the same question for the Rewards Portal: 12 months searchable in the new system, plus an Excel dump for older history. A reasonable default to propose for item 1, and one to confirm with Saudia rather than assume.
Direct answer: not the full surface. Yes for a cutover wave, with the rest landing in November.
That is the entire reason for the 12 September go/no-go. Anyone who gives a date before the register exists is guessing. That includes me.
Discovery takes two of the 9.7, cutover takes two. Five weeks does not cover a full rebuild of a custom storefront plus its Platform integrations plus the catalogue.
We are not dropping capabilities, so scope cannot be cut. What can move is when each one lands: before the cutover, or in the weeks after.
Reuse the Minimum Viable Migration already defined in the Q3 Plan. Do not invent a new one.
Everything else in the register. Contents unknown until 5 September, but the rule is fixed now.
A wave with no per-row owner is a backlog, and backlogs do not ship.
| Commit | Date |
|---|---|
| Capability Register complete, all three lenses reconciled | 5 September |
| Cutover wave and post-cutover wave split, every row owned and dated | 12 September |
| Go/no-go on the end-of-October cutover, evidence-based | 12 September |
| Al Fursan on the Ecommerce Solution at the cutover wave, 100 percent traffic | 27 October |
| Post-cutover wave complete, legacy system decommissioned | November, per-row dates from 2.3 |
Commit the cutover wave plus a dated November list. A cutover delivered on 27 October with a published November wave is a success. A full-surface promise is one nobody in the room can size today, so making it on Monday means making it blind.
Five. Two are cheap to fix on Monday and expensive to forget.
October is impossible, and we learn it on 12 September.
The migration inherits the unassigned-epic problem and nobody escalates. The Project Manager can chase a gap, he cannot own the build.
A production incident during the highest-visibility week of the year.
The frontend track stalls with no fallback, because we removed the legacy storefront from the plan.
Al Fursan sits half-migrated and the legacy system never gets decommissioned.
Deciding to build everything and then phasing it is correct. It only works if the second phase is as owned as the first.
Four things, all one-word answers, asked after the 12:00 alignment session so the working group is already behind it.
A go/no-go that can only return "go" is not a gate, it is a ceremony. A date nobody is allowed to challenge stays on the plan long after it stops being real, and everyone downstream keeps building to it.