Moving open special orders from your old system into OrderPilot

Say your old system holds 140 open special orders on cutover day. Some customers have signed but have not paid. Some sofas are on acknowledged vendor POs, due in eight weeks. Three use a fabric the mill has just discontinued. These are illustrative numbers, but the problem is familiar: none of those customers care that you changed software.

The aim is to keep their purchase intact. Give each order a clear destination, reconcile its payments, preserve the agreement, and carry forward the vendor commitment without placing it again. OrderPilot imports product templates by spreadsheet; open quotes and orders need manual entry. A cutover sheet makes that work controlled and reviewable.

Inventory the obligations before moving the records

Your starting list should describe what the store still owes each customer. An “open” flag alone will not tell you whether the sofa is unpurchased, in production, sitting in the warehouse, or delivered with a chair still outstanding.

Bring sales, purchasing, receiving, and the person responsible for customer balances into the same review. Their lists often describe different parts of the same order. Sales has the changed fabric. Purchasing has the acknowledgment. Receiving knows the ottoman arrived. The bookkeeper has the wire receipt. The cutover record needs the agreed version of all of them.

Resolve discrepancies before entry. If the signed sheet says walnut legs and the vendor acknowledgment says oak, copying both into a new system does not settle the difference. Flag the order for the person who can resolve it, and give that person a next action. A clean migration begins with a clear obligation.

Use the following columns as a cutover-sheet template. Keep the sheet in the store's controlled working files, with access limited to the people handling the move. The table is deliberately complete enough to copy into a spreadsheet without designing a second migration system.

A single row per customer order is a useful summary. Keep line-level detail beneath it or in a linked sheet when pieces have different vendors, payments, or delivery states. Do not compress a partly delivered room into “sofa order, pending.” The chair that already went home matters too.

Choose where each order will finish

The safest destination depends on the order's remaining work. You do not have to move every open record on the same day to start using OrderPilot for new business.

An order awaiting a routine final collection may be easier to finish where it began. A long-lead special order with purchasing, receiving, and delivery still ahead may benefit more from moving. A disputed specification or an unreconciled deposit belongs in review until the store can state exactly what is owed.

Write the destination on the sheet and make it visible to the team. “Both systems for now” is too vague for an individual order. One system should own the next payment request, the next vendor instruction, and the next delivery update.

The wider legacy-POS migration guide covers moving the store itself. This guide concerns the unfinished customer promises that need to survive that move.

Move the catalog before recreating the sale

OrderPilot's catalog import gives staff the templates and options they need to recreate a configuration accurately. It does not bring the old sales orders along with them.

Use Settings › Products to validate the vendor spreadsheet before applying it. Read row-specific errors and resolve duplicate or unclear identifiers. Then compare representative products with the original vendor book: not only the model name, but the offered values, option prices, costs, and rules. The vendor catalog-import guide covers this preparation. Existing orders need their historical agreed prices. A current price book is a starting structure, not evidence of what the customer bought months ago. Re-enter the sold specification and compare the resulting total with the cutover sheet before proceeding. A discontinued fabric needs an explicit resolution; choosing the closest-looking current swatch silently changes the purchase.

Customers come from Shopify's customer records. Match the existing person before creating another record, especially when an email address changed or a trade customer uses a project contact. The old order reference and the verified Shopify match should stay together in the cutover sheet.

Re-enter each chosen order in OrderPilot from that checked information. Include delivery or collection choices, the correct location, and the staff attribution. Have another person compare the record with the source documents while the new record is still being reviewed. The first-week setup plan should be complete enough for this entry to produce useful paperwork and a clear staff handoff. Migration is a poor moment to discover that every associate has administrator access or that the selling location is missing from the quote.

Bring deposits across as historical money

A deposit already received must become a reconciled payment record, not a request for the customer to pay again. Preserve the original receipt date, payment method, and transaction reference so the new balance can be explained from evidence.

Start with the settled total. Subtract actual payments and account for refunds, credits, and any agreed adjustments. Compare the result with both the old customer record and the money records your accounting team uses. When they differ, investigate the difference before posting anything in OrderPilot.

For a worked example, suppose an order's final total is $3,600, including all charges. The customer paid $1,200 by check and later $600 by wire, with no refunds. Paid-to-date is $1,800 and the remaining balance is $1,800. Your entry must reproduce that position, while retaining evidence for both receipts. The migration itself brings in no additional money.

OrderPilot can record payments taken another way, but the route depends on the record's state and your Shopify plan. Partial Record payment on a placed order requires Shopify Plus. Without Plus, a quote or draft can use the Admin deposit-order route before placement, with the separate deposit order recorded as already paid by the supported offline method. The offline-payment guide explains these distinctions.

Rehearse that route with the person responsible for accounting before a batch moves. A deposit order is a real Shopify record with tax and reporting consequences; it is not a neutral migration memo. Decide how its entry will reconcile to money already recorded in the old books, and how any connected systems will treat it. Where the tested route does not preserve the right balance and accounting treatment, leave that order in its established process until resolved. Do not use a discount simply to make a balance look right. A price reduction and a payment tell different stories. Likewise, marking a partly paid order fully paid hides an amount the customer still owes. The target is a correct sale and a correct payment history, not just a familiar number in the balance field.

After entry, compare the new paid-to-date, outstanding balance, and underlying payment evidence with the cutover sheet. Then compare the whole batch's totals. Both checks matter: matching a batch total can conceal a deposit assigned to the wrong customer.

Carry acknowledged POs forward without sending them again

An existing vendor acknowledgment is a commitment already made. The migration needs a usable purchasing record for receiving and follow-up, while preserving the fact that the order was placed elsewhere.

Create the corresponding PO from the sold lines and use the supported confirmation route for a purchase order placed outside OrderPilot. Attach the vendor acknowledgment and record the original PO or confirmation reference. The externally placed PO guide covers that distinction. This is not the moment to send the vendor an apparently fresh instruction to make another sofa. Compare the destination as carefully as the specification. An order expected at the warehouse must not become a dropship order because the customer address happened to be convenient during entry. Preserve the vendor's latest confirmed timing and any outstanding question about the build.

A PO that was already partly received needs more care. Separate the quantities still due from those already accepted, rejected, delivered, or held in the warehouse. Rehearse how those quantities will be represented before recording receipts that could add stock again. This is a cutover decision involving inventory and accounting, not a reason to receive everything and correct it later.

When a customer order spans vendors, reconcile each commitment separately. The sofa acknowledgment does not prove the side tables were ordered. If a line appears on several POs, the outstanding quantities must add up to the remaining obligation, without an extra piece hiding in a second document.

Tell purchasing which record now owns follow-up. The original acknowledgment should be available from the new PO, and the old system should direct staff to the new reference. Vendor correspondence then has a clear home for the next fabric question or revised ship estimate.

Preserve signed paper agreements as evidence

An old signed agreement should travel with the sale in its original form. Keep the complete scan, including the specification, terms, amendments, and signature, rather than retaining only the page with the customer's name.

OrderPilot supports recording a signed paper copy and attaching a scan. Record what actually happened: who signed, the original signing information available to you, and the document that supports it. This does not turn the old paper into a digital signature collected by OrderPilot. A software move alone is not a reason to ask every customer to approve a newly generated document. First compare the recreated order with the agreement already held. If the specification or customer-facing terms are changing, handle the change through the store's approval process and obtain the required agreement to that change. Keep the earlier document as part of the record.

Do not mark an unsigned order signed to get it through a placement requirement. Give it the same unresolved-signature treatment it needed before the migration. A cutover should make unfinished work visible, not make it disappear.

Run both systems with one owner for each order

Parallel operation works when the boundary is explicit. A practical approach is to start new quotes in OrderPilot from the agreed cutover point, finish some existing orders in the old system, and move the others in reviewed batches.

Choose batches around the work the team can reconcile. Orders with similar delivery states can be easier to check together than a random selection. Keep a smaller, representative rehearsal batch first: a straightforward unpaid order, an order with a deposit, and one with an acknowledged vendor PO. Expand only after the difficult parts have a repeatable answer.

Once an order moves, stop operational updates to its old record. Keep a pointer to the new number and preserve the old record for evidence. If the old system still runs orders that have not moved, the whole system cannot yet be read-only; apply the boundary at the order level until those obligations are finished.

The person reconciling a batch should not rely only on the person who entered it saying it is done. Use a second review of customer identity, line detail, total, payment position, vendor commitments, and outstanding quantities. Record the exceptions and keep them out of the completed batch until resolved.

There is no universal number of weeks to run both systems. End live use of the old one when every remaining obligation has either finished there or moved with a verified record. Preserve readable exports and original documents for the store's recordkeeping needs. Delivery of the last sofa is an operational milestone, not an instruction to delete its history.

Choose a quiet window and train the handoffs

Cutover needs time for the people who know the orders. Avoid the store's market trips, major promotion weekends, and stock counts when those people will be unavailable. Pick the window from your own trading calendar rather than assuming a software project has a naturally quiet season.

Train one complete workflow at a time. An associate should be able to create a quote, find it again, and explain the customer's next step before being shown every setting. Purchasing needs to recognize an already-placed PO. Receiving needs to know which system owns a delivery that arrives during the transition.

Shopify's retail migration guide treats POS setup, a test transaction, staff access, and inventory as distinct tasks. Give your open-order rehearsal the same practical attention. The training record should cover an actual handoff, not merely a tour of screens.

Long-serving staff bring useful knowledge to this work. Ask them which customer descriptions, vendor references, and exceptions the export leaves out. The staff-training guide explains how to make that experience part of the change. The oldest filing cabinet may contain the answer; it rarely offers a search bar.

Review the first month by exceptions

The first operating review should begin with discrepancies, not the total number of records entered. Look for failed Shopify syncs, mismatched balances, outstanding vendor confirmations, and orders whose next action has no owner.

OrderPilot shows a failed Shopify sync with its reason and a Retry action on the record or Home banner. Investigate the reason and use the retry on the existing record; creating another order to escape the error can leave two records for the same sale. Reconcile migrated deposits to the customer-deposit records with your accountant. Check both order-level balances and the total position across the cutover. Where payments, receipts, or accounting integrations have produced unexpected entries, resolve the source before moving the next similar batch.

Review customer messages as well. A migrated order should not receive a confusing fresh-quote email or a second payment request simply because a record was created. Rehearse the store's notification settings before the batch, and have a named person review what customers actually received afterward.

The cutover checklist

1. Define the boundary. Name the start point for new quotes and the person who decides where existing orders finish.
2. Build the obligation list. Include customer identity, exact lines, agreement, money, vendor commitments, received goods, and remaining delivery work.
3. Resolve uncertain records. Hold disputed specifications, unverified payments, and unclear quantities for review.
4. Prepare the catalog. Validate the import, inspect representative templates, and preserve historical selling prices on moved orders.
5. Rehearse the payment route. Use the store's Shopify plan and record state; reconcile the reporting effect before entering a batch.
6. Preserve agreements and POs. Attach original signed documents and acknowledgments; distinguish existing commitments from new purchases.
7. Review each batch. Compare every order and the batch totals, with a second person checking the result.
8. Assign the operating record. Stop updates to moved records in the old system and make the new reference easy to find.
9. Watch the first handoffs. Inspect customer messages, vendor follow-up, sync failures, receipts, and balances.
10. Retain the evidence. Keep the original records accessible while the remaining obligations finish and for the store's continuing recordkeeping needs.

Before scheduling entry, work through recording payments taken another way with the person who reconciles your deposits. Once the money route and vendor commitments are clear, the team can move each order with a record it understands.

Sources

1. Migrate your retail store — Shopify Help Center.