Month 1: freeze the scope and map the chart of accounts
Start by deciding what you are not migrating. The default request is every transaction since 2015. The right answer is almost always two fiscal years of detail plus opening balances, with Accurate kept read-only for the statutory retention period. DJP can look back five years, so the old system stays available as an archive instead of becoming a data-conversion project of its own with its own budget and its own delays.
Chart of accounts mapping is where the project is won. Export the Accurate account list into a spreadsheet with five columns: old code, old name, new ERPNext account name, root type, and account type. ERPNext distinguishes group accounts from ledger accounts and cares about account type — Receivable, Payable, Stock, Tax, Bank, Cash — because half the standard reports depend on it. Getting account type wrong is the most common cause of a stock ledger that refuses to reconcile.
- Keep the numbering scheme finance already knows; renumbering mid-migration costs goodwill you will need later
- Collapse accounts nobody has posted to in two years instead of carrying dead structure forward
- Map every tax account explicitly: PPN Keluaran, PPN Masukan, PPh 23 payable, PPh 21 payable
- Decide cost centre and project dimensions now — retrofitting them after go-live means reposting history
- Have the external accountant sign the mapping sheet before anyone configures a single record
Months 2 and 3: master data and opening balances
Master data is four files: customers, suppliers, items, and employees. Expect duplicates. A typical Accurate customer list of 1.800 names collapses to about 1.500 once you merge PT Maju Jaya, PT. Maju Jaya, and Maju Jaya (Pak Budi). Deduplicate in the spreadsheet rather than in ERPNext, and assign one owner per file who is allowed to make the final call. Without that owner, the file never actually gets clean.
Opening balances follow a specific order. Post the trial balance as a journal entry against Temporary Opening. Load open receivables and payables as individual invoices flagged as opening entries, never as one lump sum, so the aging report means something on day one. Bring stock in through a Stock Reconciliation with quantity and valuation rate per warehouse. Fixed assets come last, with gross value and accumulated depreciation separated so the depreciation schedule continues correctly.
Month 4: configuration and the first dry run
Month four is configuration: naming series, tax templates, warehouses, item groups, price lists, approval workflows, and print formats that match the documents customers already receive. Then run a full dry run. Load the migration files into a fresh instance end to end, time each step, and record every error. The dry run is not a test of the data; it is a rehearsal of the cutover script, and you repeat it until it is boring.
- Time every load step so the cutover runbook carries real durations instead of optimistic guesses
- Freeze the migration file format after the dry run; late column changes break the scripts silently
- Validate control totals after each load: AR total, AP total, stock value, and trial balance
- Rehearse the rollback too, including how you reopen Accurate for transactions on Monday morning
Month 5: a parallel run finance can survive
A parallel run means finance enters the same transactions twice for a month. It is exhausting, and it is the only reliable way to find the gaps before customers do. Keep it to one month and reduce the scope deliberately: full parallel on sales, purchasing, and inventory; sample-based on payroll and fixed assets. Reconcile five reports weekly — trial balance, AR aging, AP aging, stock balance, and the PPN position against SPT Masa.
Set a numeric exit criterion before you start. Ours is a trial balance variance under Rp 100 ribu, AR and AP aging matching invoice by invoice, and stock value variance under 0,5 percent with every remaining line explained. If you do not write the criterion down, the parallel run ends when everybody is tired rather than when the numbers agree, and the difference shows up at the first month-end close.
The cutover weekend
Cutover is a weekend with a written runbook and a named owner for every step. Friday 17:00, Accurate stops accepting transactions. Friday evening into Saturday morning, final extracts and the opening balance load. Saturday afternoon, control-total validation. Sunday morning, a business smoke test: create a sales order, deliver it, invoice it, receive payment, check the GL. Sunday 18:00, go or no-go, decided by the sponsor rather than by the consultants.
- Publish the runbook a week early so every step has a named owner and a stated duration
- Set the no-go criteria in advance; a decision made at 22:00 without them is always go
- Keep Accurate live but read-only, and remove edit rights so nobody quietly posts there on Monday
- Staff the warehouse from 06:00 Monday — goods receipt is where day one actually gets tested
The weeks after go-live
Plan four to six weeks of hypercare with consultants physically present rather than sitting behind a ticket queue. The first month-end close is the real go-live: run it with the implementation team in the room and expect it to take longer than the old one did. Budget fifteen to twenty percent of project value for the six months after cutover. That money is what turns a technically finished migration into a system people actually trust.