Legacy vs. modern
MOM compatibility
A feature-by-feature comparison of legacy MOM (MultiChannel Order Manager) and OpenMOM. Every row is traced to the live legacy database, documented API, implementation, and tests.
Live shipped and covered by tests
Improved exceeds legacy capability
In progress active migration work
Planned designed and scheduled
Gap not yet designed or decision pending
Excluded deliberately not carried forward
56
Live
3
In progress
3
Planned
7
Open gaps
3
Excluded
72 features tracked · Status as of Sep 6, 2026 · Updated as roadmap phases ship
Show
01 · Core business entities
Customers, orders, products
The foundational data model — customers, orders, products, and the relationships between them. Fully shipped, including migration from legacy MOM databases.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Customers | CUST table, 50+ columns, full API surface for create/read/update |
Full customer CRUD with addresses and stored payment methods; legacy CUST migration proven live — 71,386 customers and 100,900 addresses loaded from the real estate |
Live |
| Customer search | Fuzzy name/address matching plus filtered bulk pulls | Find by email, phone, or name — exact and fuzzy, with distinct not-found and ambiguous-match errors | Live |
| Contacts & addresses | Linked ship-to / bill-to / sold-to / gift records via relationship tables | Typed address and contact relationships covering all legacy roles | Live |
| NCOA processing | Define an address list, export DEMOLIST.xls, process the provider-returned file, and update customer addresses |
Provider-neutral NCOA workspace with minimized export snapshots, validated result import, operator review, stale-address conflict protection, and transactional address updates | Live |
| Contact history | Phone and written contact logs per customer | Contact log with list and add operations | Live |
| Custom fields | Demographics system that alters live tables per company — confirmed on a production instance | Custom fields stored as data, with definitions — no schema changes at runtime | Live Improved |
| Orders (header) | CMS table plus a family of order APIs for addresses, shipping, and payments |
Whole-order creation in one call, plus get/update; 127,184 legacy orders loaded in the live rehearsal | Live |
| Multi-step staged creation | Orders built up across multiple screens before commit | Optional draft → commit flow — design decision pending | Gap |
| Order line items | ITEMS table with add/detail/delete API methods |
Add/update/remove line items with pipeline guards — immutable once picking starts; 235,196 legacy line items loaded | Live |
| Products / stock items | STOCK table with 20+ product-attribute columns |
Products with attributes, images, and retail-price cascading; 10,664 legacy STOCK products loaded |
Live |
| Product composites / kits | Component tables tying parent products to inventory items with quantities | Kit bills of material with quantity components | Live |
| Pricing / special pricing | Per-source, per-customer, per-catalog discount rules | Pricing rules with priority, date range, and customer/source/product scope, plus supplier buy prices | Live |
| Suppliers / vendors | Supplier table plus per-supplier cost records | Vendors with typed pricing records; 169 legacy suppliers loaded | Live |
02 · Order processing
The pipeline & its rules
MOM's staged processing pipeline with "stage latches" — the core workflow that drives fulfillment. The pipeline itself, holds, notes, per-line pick/pack progress, totals, and returns are all shipped.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| 10-stage pipeline | E-Payment Approval → Picking → Packing → Gift Cert → Box Label → Notices → Drop Ship → Catalog Labels → Shipping → Invoicing. Stage latches prevent skip-ahead. | Pick, pack, ready-to-ship, ship, and invoice stage tools with the same stage-latch semantics | Live |
| Order holds & stop-review | Hold-type flags on the order plus hold/stop-review API calls | Hold and release with prior-status restoration, stop-review, held-state preserved in migration | Live |
| Order notes | Three distinct note types: internal, box-label instructions, fulfillment instructions | Typed notes — note, instruction, memo, box label — editable and removable with a full audit trail | Live |
| Totals calculation | Dedicated calculation calls, single and batch | Server-side atomic recalculation, single and batch | Live |
| Gift messages | Six fixed lines per item, plus box-label gift text | Gift messages as open-length lists — no fixed cap, no continuation flag | Live Improved |
| Batch order processing | Orders grouped by stage, configured via Global Parameters | Batch processing tool with typed stage filters, returning per-order success/failure | Planned |
| Packer's workstation | One-at-a-time scan-and-pack screen, alternative to batch | Single-order pack workflow — scan barcode, confirm items, assign box | Gap |
| Multi-ship orders | Ship-to address per line item | Line-item-level ship-to references — same capability, typed | Live |
| Per-line picked/packed quantities | Package-level detail tracks what's been picked and packed | Per-line picked/packed quantities recorded across the pick/pack window, separate from shipped quantities | Live |
| Returns / RMAs | Return authorization, restock or disposal, exchange, refund | Routed RMA/returns workspace covering creation from shipped lines, authorization, receipt, restock, disposal, exchange, refund, and cancellation | Live |
| Point of Purchase / counter sales | CMS.POPENTRY identifies POP orders; MOMUSER.CASHIER and POPWARE identify cashier and warehouse context |
Routed scanner-first counter workspace over real orders, inventory, exact split tenders, invoices, durable receipt snapshots, voids, and multi-tender returns/refunds. Review fixes are implemented and pending final independent review. Historical register/drawer ETL is evidence-deferred because no source entity is documented. | In progress |
| Exclusive edit locks | Editing an order blocks the MOM UI for everyone until saved (SAVE_PARTIAL_ORDERS) |
Atomic commits instead — no locks to hold or lose | Excluded |
03 · Payments & financial
Payments, invoicing, journals
Payment methods, the payment lifecycle, invoicing, and the A/R journal are shipped — tokenized by design. Accounts payable is in too: supplier bills commit from received purchase orders, payments apply to bills with exact-decimal balances, and end-of-day deposit batches record the banking event.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Credit card processing | Raw card numbers and security codes stored across several tables | Tokenized only: last four, brand, expiry, processor token. No raw card data column exists — and PAN-shaped inputs are rejected at the API. | Live Improved |
| eCheck / ACH | Routing and account numbers stored directly | ACH payments tokenized via the processor — bank details never touch the database | Live Improved |
| Check / invoice / COD / PayPal | Dedicated API methods per payment type | One typed payment-method set covering card, check, ACH, COD, invoice, and PayPal | Live |
| Payment capture & refunds | Capture, void, and refund through merchant integrations | Capture, refund, update/remove payment lifecycle — refunds post as linked ledger rows, never mutations of captured funds | Live |
| Card on file | An undocumented customer-table column with a raw card number, plus a separate tokenized path | Processor vault tokens only, migrated from legacy CCTOKEN records — 2,629 payment methods loaded in the live rehearsal with zero PCI violations, never raw card data |
Live Improved |
| Gift cards | Full card number and PIN stored | Balance tracked via processor reference — no card number stored. Redemption contract in design. | Planned |
| Invoicing | Invoices generated at the final pipeline stage | Invoice generation on order completion; 153,494 legacy invoices loaded with exact decimal totals and order reconciliation | Live |
| A/R journal | Dual-entry journal with a fixed vocabulary of transaction codes | Journaling in the schema with the same transaction codes as typed enums, plus G/L account mapping and posting | Live |
| Accounts payable | Vendor payables and bank-deposit reporting | Routed Payables workspace: supplier bills commit directly from received purchase orders (received-minus-billed per line); payments record with check references and apply/unapply against exact-decimal balances — and method/date-filtered deposit batches record the banking event over captured funds | Live |
04 · Inventory & purchasing
Stock, warehouses, POs
Stock, purchasing, receiving, and drop-shipping are shipped — a 649,086-transaction legacy inventory ledger migrated and chain-verified, and the whole domain loaded end to end in the live rehearsal.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Inventory / stock levels | On-hand, committed, backorder, and available quantities | Stock reporting with committed-demand allocation; the full legacy INVTRANS ledger migrates chain-verified with verbatim running totals — 649,086 transactions loaded in the live rehearsal |
Live |
| Warehouses | Warehouse table per company | Warehouses per tenant; single-warehouse estates like the live source load under the default model — shared-inventory crosswalk deferred with recorded evidence | Live |
| Bins & lot tracking | Bin and inventory tables per warehouse | Bin/lot model in place — 1,426 legacy bins migrated under the single-warehouse model in the live rehearsal | Live |
| Shared inventory | Cross-company warehouse groups (MOMSHARE) | Explicit shared-warehouse-group grants — deferred by owner decision with recorded evidence (this estate has no shared inventory); activates when a real migration customer needs it | In progress |
| Inventory adjustments | Manual unit/cost/transfer adjustments via the AIM module | Adjustment and allocation operations with an audit trail | Live |
| Purchase orders | PO APIs for header and detail management | Full PO lifecycle — create, submit, receive, close — with legacy PO migration covering all five statuses; 29,272 POs and 47,264 lines loaded | Live |
| Receiving | Manual delivery screen or barcode scan-and-receive (AIM module) | Per-line and bulk receiving with partial receives, commit, and automatic inventory allocation | Live |
| Drop shipping | Flagged line items become automatic POs in batch processing | Parallel drop-ship workflow, including drop-ship origin orders in migration | Live |
| Reorder points | Manual or auto-calculated from sales history | Reorder reporting with configurable thresholds per product | Gap |
05 · Shipping & fulfillment
Carriers & packages
Carrier and rate management, package tracking and maintenance, and quick-print document output are shipped — one shipment model replaces MOM's 12+ per-carrier table families. Direct carrier label integrations are not built yet.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Shipping methods & rates | Carrier services with charge rules, zone and rate tables | Carriers, rate bands, and rate estimation; 33 legacy carriers loaded in the live rehearsal | Live |
| Box / package tracking | 12+ near-identical per-carrier share tables | One carrier-shipments model with line items — 131,063 shipments and 205,302 line items loaded with package/address/content reconciliation | Live Improved |
| Direct carrier integrations (UPS / FedEx / DHL) | Per-carrier modules — direct UPS API, FedEx tables, two generations of DHL tables | Carrier-agnostic shipment records today; direct label and rate integrations not yet built | Gap |
| Package info & quick-print | Package instructions, charges, and label/document output | Order-workflow package maintenance (weights, dimensions, service, charges) with a pre-shipment window; structured packing slips, shipping-label data, and invoices render in browser print preview with a generation log — no invented server PDF | Live |
| Address validation | Licensed add-on module (USPS/CASS certified) | Pluggable address-validation provider — module decision pending | Gap |
06 · Integrations & channels
Channels, tax, accounting sync
The channel model, tax engine, and multi-company support are shipped. The import/export execution engine and per-marketplace sync workflows are the remaining work.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Channel listings (Shopify / Miva / ShopSite / etc.) | Separate licensed modules, each with its own table family | One channel-listing entity parameterized by channel type; per-channel variant tables collapsed into one | Live Improved |
| Marketplace / storefront sync | Amazon connector, SiteLINK hosted storefront, web auction module | Per-channel sync workflows; SiteLINK itself is superseded by any-storefront adapters | Gap |
| Import/Export module (IEM) | A field-mapping job engine spread across six wizard tables, forked across two generations | One import/export engine — jobs, source files, field mappings, history, and durable batch execution with crash-resume checkpoints. Customer and stock imports execute today; order/rates/zones remain | In progress |
| Tax calculation (TaxJar / Avalara) | Four-tier jurisdictions with five tax classes each, plus two parallel connector table sets (19 tables combined) | One jurisdiction table with a level discriminant, normalized tax classes, and one pluggable provider interface | Live Improved |
| QuickBooks integration | Two generations: legacy Desktop (qbXML) plus modern QuickBooks Online OAuth | QuickBooks Online OAuth2 configuration — the legacy Desktop protocol is excluded as superseded | Live |
| Multi-company controller | Up to 50 isolated company data stores per license | Shared-database tenancy with engine-enforced isolation — not capped at 50 | Live Improved |
07 · Security & compliance
Permissions, audit, PCI
RBAC, audit logging, PCI-safe payments, and tenant isolation are shipped and tested. Identity and permissions were migrated from the live estate in the Phase 7 rehearsal — with zero PCI violations.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Role-based access control | Menu-coordinate permissions plus hardcoded capability columns on the user table | Permission catalog and user grants — migrated from SECDEF/SECUSER with suspend/revive convergence and roles derived from legacy capability flags; 35 users and 108 permission grants loaded in the live rehearsal |
Live |
| Audit logging | Activity records with maker/checker (enterer + authorizer) timestamps | Audit log with before/after values, actor, and review workflow — same two-person-integrity pattern | Live |
| Legacy audit history migration | 57,000+ legacy USERACTIVITY rows |
Permanently disabled at the current source — the rows are nearly all blank-actor and unattributable, and migrating them would fabricate an audit trail. Future sources with attributable actor data can enable under a confirmed actor policy. | Excluded |
| PCI compliance | Raw card numbers in 8+ tables, security codes in 4, static-key encryption from the early 2000s | No raw card data anywhere — card, bank, and credential records are excluded at extraction and quarantined. Tokenized storage only — the full live estate migrated with zero PCI violations. | Live Improved |
| SSN / tax ID storage | Social security numbers stored as plain text on the user table | Not migrated — a compliance liability, not a feature | Excluded |
| API credentials | Plaintext in merchant and connector configuration tables | All credentials as references into a secrets manager — never in the schema | Live Improved |
| Tenant isolation | Database-per-company, enforced only by the application | Row-level security enforced by the database engine itself, per transaction — the app role cannot bypass it | Live Improved |
08 · Subscriptions & recurring
Three mechanisms, not one
MOM has three distinct recurring-order mechanisms — not one feature under different names. The subscription and club domains are shipped; migrating live data waits on a source that has any.
| MOM feature | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Magazine / periodical renewals | A flat subscription table tied to publication products | Publication-linked subscriptions with renewal tracking | Live |
| Club membership plans | Plan templates, product rosters, per-customer enrollment, shipment history | Membership plans, enrollments, and shipment history as linked records | Live |
| Batch order making | "Clone these existing orders with a new item substituted" — e.g. book-of-the-month | Batch clone with a typed substitute-item workflow | Planned |
| Continuous order forms | A possible third recurring mechanism — columns not yet fully read | Under evaluation — confirming whether this is a distinct feature before designing anything | Gap |
09 · API surface
How the two connect out
The API is live, with schema-validated tools, structured results, and no session state. This is the layer everything above ships through.
| Aspect | How MOM does it today | How OpenMOM does it | Status |
|---|---|---|---|
| Protocol | A Windows-only COM API — ~400 methods, single-threaded | A tool-based API server covering every domain above — built for automation and AI agents | Live |
| Authentication | Session-based: connect, log in, keep a session alive | Authentication on every call — no session state to manage | Live Improved |
| Error handling | Bare integer return codes, error text in a side channel | Structured results — success with data, or failure with a code and message | Live Improved |
| Input validation | Everything passed as strings — booleans as "T"/"F" | Schema-validated inputs — real types, strict schemas that reject unexpected fields | Live Improved |
| Pagination | Stateful two-call cursors tied to your session | Stateless cursor pagination | Live Improved |
| Concurrency | Exclusive edit locks — editing an order blocks the MOM UI until saved | Optimistic concurrency via versions — no locks | Live Improved |
| Platform | Windows-only | Cross-platform — Docker, Linux, macOS, any cloud | Live Improved |
10 · Migration strategy
How the data moves
How legacy data moves from MOM's SQL Server to OpenMOM's PostgreSQL. The migration framework is live and covered by 380+ tests — and proven end to end against the full live MOM estate in the September 2026 rehearsal: 1,889,649 rows extracted, 1,768,484 loaded, zero errors, zero PCI violations.
Step 01
Extract
Read-only connection to the live MOM database with a manifest of supported mappings. All ~413 tables cataloged with column-level detail, deterministic IDs, and PCI exclusions applied up front.
Step 02
Transform
Bridge columns on every core entity preserve the link back to the MOM record. Enum codes translated explicitly. Raw card, bank, and credential data never enters the pipeline.
Step 03
Validate
Row-count reconciliation, exact financial totals, and source-total cross-checks. Anomalies land in a durable quarantine — classes are accepted only by explicit operator sign-off, and nothing is dropped silently.
Step 04
Cutover
Full-table reruns and delta runs converge changes without losing history. Cutover is gated on exit criteria — zero unapproved rejections, reconciled counts — with a rollback window and side-by-side coexistence.
Coming January 2027.
The repository opens after full testing, 100% parity with MOM 10, and verified improvements beyond the legacy system.