Replace the storefront and keep the print MIS

Follow the order through the boundary

A customer chooses a product, quantity, material, finishing and delivery details. The storefront may calculate a provisional price or ask another service for the authoritative amount. It receives artwork or a design reference. At checkout it creates an order. The MIS expects a production job, which may have different required fields and identifiers. A map between those models is the core of the replacement.

The map needs to state which system owns each value. If the MIS owns a stock code, the front end should use that code or a documented translation. If a product option affects production routing, a text note is not enough. If artwork is stored outside both systems, the job must carry a durable reference and a retrieval rule. A human should be able to inspect what was accepted, not just what the storefront attempted to send.

Status must travel in the other direction when the buyer or support team depends on it. "Order placed" at checkout and "job accepted" in production are different events. A customer should not be told that production has the job merely because payment completed. The integration can expose the distinction and recover when the MIS rejects a submission.

Failure paths decide whether the design is safe

Connections time out. A webhook can arrive twice. An operator can correct an order after its first submission. The design needs a stable order identifier and an idempotent create-or-update rule so retries do not produce duplicate jobs. Rejections need a reason and an owner. A queue with no visible failure state simply moves manual retyping into a less obvious place.

A useful test set includes ordinary products, unusual options, artwork revisions, cancelled orders and failures at each handoff point. The test asks whether one customer order becomes one correct job and whether an operator can tell which system is authoritative after an error. A successful HTTP response alone does not prove that production received a complete job.

The new front end may also need historical customer accounts, designs and reorders. Those features can affect the migration even if the MIS holds all production history. We would check which data can be exported, which rights attach to it and whether a customer could still repeat a previous order after cutover.

A contained replacement

The best route may be to retain the MIS, replace the customer-facing layer and add an adapter that documents the contract between them. That is a hypothesis to test, not a promise from a distance. If the MIS has no authorised interface that carries the required fields, the decision changes. The business may need a vendor-supported route, a different boundary or a wider migration.

An assessment should compare those paths before any cutover. It should also identify a rollback route while the old storefront can still accept orders. Once new jobs have entered production, reversal may require reconciliation rather than a simple DNS switch. Those operational details belong in the decision, even when the reason for the project began with an unattractive storefront.

Test the interface before committing

A small technical proof can establish whether the MIS interface carries one complete job. It should send a representative product with a non-trivial finishing combination and an artwork reference, then inspect the record created in the MIS. It should deliberately send an invalid value and confirm the rejection is visible. That result is more useful than a high-level promise that the systems can communicate.

The proof must also test correction. If a customer changes quantity after checkout or an operator updates artwork, the integration needs a defined revision route. A second create request may produce a duplicate job; an update may overwrite production work already started. The acceptable behaviour depends on the MIS state and the operation's change policy, so it belongs in the interface contract.

Finally, verify how identifiers survive an outage. A message may be sent, time out and then be retried after the receiving system has already created a job. Idempotency cannot be assumed from the transport. The receiver or adapter needs a stable external key and a way to look up what happened before trying again.