Nobody decides to run a company on spreadsheets. They drift into it. A quote template here, an inventory tracker there, a desktop accounting package that nobody dares to upgrade. It works until the day it does not, usually a month-end close that takes two weeks or a stock count that disagrees with the ledger.
The fix is not mysterious. It is one connected system, put in with discipline. At 1800 ERP we do this in about six weeks, on a fixed scope with a dated plan, on ERPNext and the Frappe Framework.
This post is the playbook. Three phases, one rule about data, and the short list of things that make go-lives fail.
Weeks one and two: discover and blueprint
Start by admitting what the business actually does, not what the process document says it does. We run a discovery workshop with the people who touch the work: whoever raises purchase orders, whoever chases invoices, whoever counts stock. Every spreadsheet and every legacy screen gets mapped to a place in the new system, or consciously retired.
The output is a blueprint. Which modules go live now (for most companies that means Accounting, Selling, Buying and Inventory), which ones wait, what the chart of accounts looks like, what gets migrated and what gets left behind. Fixed scope means this document is the contract. If it is not in the blueprint, it is not in week six.
Two weeks feels short for this. It is enough when the right people are in the room and decisions get made in the meeting rather than after it.
Weeks three to five: configure and migrate
Configuration moves faster than people expect. Company setup, currencies, tax templates per country (VAT, GST, sales tax), warehouses, item groups, customer groups, print formats. Standard first. Custom only where the blueprint says so, and then as Frappe apps that behave like native features: same UI, same permissions, same database.
Migration is where the schedule lives or dies. Master data comes over first: customers, suppliers, items, price lists. Then opening balances. Our rule is simple. Balances are reconciled to the last cent before anyone posts a live transaction. Trial balance to trial balance. Stock ledger to physical count. Receivables by customer, payables by supplier. If a number is off, we find out why. We do not carry the difference forward and hope.
This is also where exits from Tally, Sheets and aging desktop systems get done properly. Legacy data is rarely clean, and cleaning it is part of the work, not a surprise discovered on the last day.
Week six: train and go live
By week six the system is configured, the balances match, and the team has already seen it during migration checks. Training is by role, on your data, in your workflows. Nobody learns the ERP in the abstract. They learn how to raise a purchase order, receive stock, invoice a customer, close the month.
Go-live is a date on the plan, not a feeling. After it comes thirty days of hypercare, where questions get answered the same day and small adjustments happen quickly. Then the ongoing work: support, backups, upgrades.
Why go-lives fail
Across 120+ implementations the failures we have seen share a few causes. None of them are technical.
- Scope that never closes. Every week someone adds a module or a workflow. Six weeks becomes six months.
- Migrating dirty data and hoping. Unreconciled opening balances poison every report that follows, and trust in the system never recovers.
- Training the software instead of the job. People go back to their spreadsheets the moment the screen stops matching their day.
- No owner on the customer side. Someone has to decide, and decide quickly. Committees do not go live.
- Customization first, standard later. Bespoke work should sit on top of a working standard system, not replace it.
Each one is a discipline problem, not a software problem. That is good news, because discipline is cheaper to fix.
What you get on the other side
One source of truth, in real time. Finance, sales, inventory, and later manufacturing, HR and projects, all on the same records. AI built in rather than bolted on: assistants that draft entries, reconcile records, forecast demand, and answer a question like "Overdue AR by customer group?" in chat. An open-source foundation with no per-user license fees, where you own the code and the data.
Six weeks is not a stunt. It is what happens when scope is fixed, data is reconciled, and people are trained on their own work. If you are still running on spreadsheets, that is where we would start.
Salman Mulani
Founder, Onesage Inc.

