Cutting over from your old system: the last legacy date, open transactions and who may stop go-live

By the end of this guide your old system has taken its last transaction, everything still open has come across exactly once, and a named person has said go. It is for the implementer running the project, the integrator running the final load, and the finance manager who signs the opening figures.

The cut-over, at a glance:

1. Fix the last legacy date.
2. Sort every open transaction: a document, a balance, or nothing.
3. Rehearse the whole load in a test tenant.
4. Freeze the old system, extract, and write down the watermark.
5. Load in order and prove it.
6. Hold the go-live decision, with an owner on every line.
7. Watch the first week against records BigLedger did not produce.

BigLedger’s backend, as read for this guide, holds no cut-over date, no go-live switch and no parallel-run mode. Steps 1, 6 and 7 are people’s jobs from start to finish.

Meet GadgetSphere

GadgetSphere Distribution Sdn Bhd (GSD) leaves its old wholesale system at the 2025 year end. The last legacy date is 31 December 2025; trading reopens in BigLedger on Friday 2 January 2026. On the last day GSD holds 412 open customer documents netting to RM 2,350,000, supplier documents netting to RM 1,780,000, 38 undelivered sales orders and 9 purchase orders in transit.

Before you start

• The tenant is set up as far as e-invoice switch-on: rows 1 to 11 of the setup order.
• You have a test tenant for the rehearsal. BigLedger runs no sandbox, so ask for one by name.
• Somebody has agreed to keep the old system readable, and for how long.

Step 1: Fix the last legacy date

The outcome: one written date that every opening figure is “as at”.

Choose a month end. The bank balances you bring across are reconciled balances at the cut-off date, and on the purchase-invoice route the stock account is filled only by the cut-off month’s close, so a mid-month date gives you two half-months to explain. Mid-year, the trial balance also carries income and expenses to date; the finance manager decides before the rehearsal how they come across.

Then write the rule for transactions that straddle it: a document belongs to the system its date falls in. A GSD invoice dated 31 December is raised in the old system even if it is typed on 2 January; one dated 2 January is BigLedger’s, entered as itself and never as an opening document.

BigLedger does not hold this date for you. The project lead writes it into the cut-over plan and the finance manager signs it. Afterwards a LOCK_TXN status on the legacy months keeps new documents out of them, set only once the opening documents dated in those months are final: lock first and the import’s own documents are refused when they finalise. Stock transfers and journal imports still get through (what the locks stop).

Step 2: Sort every open transaction

The outcome: everything open on the last legacy date, marked document, balance or nothing.

Why open items are documents. A receipt after go-live is knocked off against a document, not against a figure, so each unpaid invoice has to exist. It carries the legacy number as its reference and only what is still owed, on a service item: you are re-creating the debt, not the sale.

Why settled ones are nothing. A settled invoice is already inside the balances: its revenue in the ledger figures, its cash in the bank balance, its goods out of the count. Recreate it and finalise it, and BigLedger starts the same posting as for any invoice: a receivable nobody owes, revenue counted a second time, stock taken out again if the line is a stock item. Whoever runs the old system keeps that history readable for as long as your auditor or tax adviser says you must.

Open orders. An order is a promise, not a balance, so it is not in the opening figures. Key or import each one for the undelivered quantity only (sales order File Import, purchase order File Import). The sales administrator checks the 38 orders against the old order book; the buyer checks the 9.

The pair that straddles. Goods received before the cut-off are in your opening count; if the supplier’s bill arrives after it, in the standard purchase flow an ordinary purchase invoice books that quantity in a second time, because the invoice is the document that moves stock. Goods delivered before and invoiced after are the mirror. Nothing ties a late bill to an opening count, so the accountant lists both kinds on the last legacy date and agrees how each will be billed before the first one arrives. The check after each: the item’s stock did not move.

What no export lists

Each needs an owner before the freeze.

• Stock the count cannot see, and stock it should not. Yours but in transit, or held by a consignee; on your shelf but a consignor’s. The stock controller lists both before the count is keyed.
• Payments and receipts not yet on the bank statement. The accounts clerk keeps the old system’s last bank reconciliation: the first statement in BigLedger carries lines whose other half is there.
• Open documents in a foreign currency. Prove one in the rehearsal, through to its first payment, before loading the rest.
• The schedules behind a balance. Fixed-asset register, prepayments, accruals, intercompany balances by counterparty: the accountant keeps them and ties each to its opening balance.
• E-invoices the old system has not finished. Unsubmitted, rejected or awaiting cancellation: a named person finishes them there before go-live, until the list is empty.

Step 3: Rehearse the whole load

The outcome: you know the load’s duration and which files fail.

In the test tenant, run the opening balance migration end to end with last month’s figures, then its six-number check. Time it: that is the least the old system must stay frozen in Step 4, before the extract, the proof and the decision are added. The finance manager signs the rehearsal’s six numbers.

Step 4: Freeze, extract, and write down the watermark

The outcome: nothing changes in the old system after the extract unnoticed.

Freeze if you can. GSD makes the old system read-only at close of business on 31 December and loads over the holiday. The watermark is simply that moment.

If trading cannot stop, there is still one snapshot date. The watermark is the time of the extract, kept by the integrator: BigLedger records none. After the load, extract again whatever was created, corrected or back-dated on or before the snapshot date since the watermark, and sort it through Step 2. Take the last such extract with the old system frozen, however briefly, or there is always one more. The integrator proves it by value: the old system’s outstanding totals as at the snapshot date, re-run after the freeze, equal the totals loaded.

What a second upload does depends on the document type. This holds when no row of the file fills the LINE_CLIENT_DOC_1 column, as in the opening-balance templates:

The match is on the branch, the customer or supplier record and the reference, and not the date. A corrected branch or a different customer record makes a new document; the same reference from an earlier year, same branch and customer, finds the old one. With LINE_CLIENT_DOC_1 filled on any row, no row of the file is matched by reference: only a line repeating a line reference under the same branch, reference and customer is refused, and everything else is created as new documents.

So a correction file holds only the documents that changed, each one whole, never the full extract again, and a deposit file is uploaded once. An opening stock file reuses one reference per branch, so give a top-up file for the same branch its own reference: against a draft first load it would overwrite it, and against a final one it is refused. If a stock file fails on a serial number part-way, the import tries to undo what it had written; check that branch’s opening invoices, lines and headers, before you upload again.

The JSON import of a sales invoice runs through this same importer. A load that creates documents directly through the API has its own duplicate key, settled once and written down.

Step 5: Load in order and prove it

The outcome: the six numbers agree before anyone posts a live document.

Follow the migration sequence: stock, customers, suppliers, cashbooks, ledger. Keep the company’s E-Invoice Status at DISABLED while outstanding documents import and finalise, so none of them is sent to LHDN. The status is read by the background step that runs after FINAL, not at the click, so give the last opening document time to finish posting, turn the status on before the first real sale, and search the e-invoice Posting Queue for a legacy reference: one there means you switched on too soon. A sale finalised while the status is off is not picked up later. Then filter every import for DRAFT, run the six-number check, and lock the legacy months.

The opening-balance guide also allows the customer and supplier uploads to follow go-live, when the final ageing arrives late. That switches e-invoicing off for the whole company while you trade: do it out of hours, finalise no sale until the status is back on, put the two numbers on the Step 6 list with a date and an owner, and expect receipts to wait unapplied until their invoices are in.

Step 6: Hold the go-live decision

The outcome: one meeting, one list, and two named people who can each say stop, before the first live document.

Who may stop it. The finance manager stops go-live on any number that does not agree, and the project lead on any line without proof. Either can stop; it takes both to proceed. Write the decision down. Agree beforehand what a stop means: who reopens the old system, and that a new last legacy date makes the loaded figures stale.

Step 7: Watch the first week

The outcome: for a fixed week, somebody proves BigLedger against records it did not produce.

Treat no finalised document as a rehearsal. Finalising starts the real posting — the journal, the stock movement, a number and, where the document qualifies and e-invoicing is on, the queue toward LHDN — so only one system finalises real documents. If both submitted the same sale to LHDN, it risks being reported twice.

GSD trades in BigLedger from 2 January with the old system read-only. Each morning for the agreed week the accounts clerk compares yesterday in BigLedger with what BigLedger did not write: receipts against the bank and card settlement reports, sales against the signed delivery orders, and the stock of twenty fast-moving items against a count. A business that keeps trading in the old system instead re-keys each day into the test tenant and compares count and total per branch. The finance manager reads the differences daily.

What success looks like

On the first live morning, in thirty seconds: the newest document in the old system is dated on or before the last legacy date; the Debtor Report’s outstanding total as at the cut-off date is the legacy ageing total; and the first live invoice shows a posted journal in Trace Document and, once its clocks have run, reads Valid on the e-invoice listing.

Common mistakes

Related documentation