Migration & Onboarding
Moving your ledger into the cloud, step by step
Migration is not a single transfer of files. It is a sequence — extract, agree, convert, verify, then run in parallel long enough to trust the result. This page walks that sequence in the order it happens, with the checks at each stage.
What migration covers
A sequence, not a transfer
Starting point
Starting where you are
Most migrations we handle start from one of three places: a desktop file such as ABSS, a spreadsheet-based ledger, or an existing cloud subscription that has drifted. Each has a different extraction path, and the first task is establishing what records exist, in what format, and how far back they go.
We ask for read-only access to the current system before anything else. The old ledger keeps running while we work on the new one, so nothing stops during the transition.
Where firms start
- ABSS desktop file
- Spreadsheet ledger
- Existing cloud, drifted
Agreeing the date
Agreeing the cut-off date
A migration needs a single date on which the old ledger stops and the new one starts. Everything before belongs to the historical record; everything after is posted in the new system.
Choosing that date badly creates the most common migration problem: a period where transactions exist in both ledgers, or in neither. Timing matters too. If your GST quarter or your year-end falls in the migration window, it is usually better to complete the filing on the old system first and migrate after. We will say so if the calendar looks tight.
Before the date
Historical record on the old ledger
On the date
Opening balances converted
After the date
Posted in the new system
Historical records
Extracting the historical data
We pull the chart of accounts, the trial balance at the cut-off date, the aged debtors and creditors listings, the fixed asset register, and the GST control accounts where applicable. For firms with several years of history, we agree how much needs to come across in a usable form and how much can stay in an archive export.
Nothing gets deleted. Your historical records remain accessible after migration, and the trail from the old ledger to the new opening position is documented.
Opening balances
Converting opening balances
Opening balances are where migrations succeed or fail. Each balance sheet account is converted at the cut-off, and the conversion has to balance: debtors, creditors, bank, fixed assets, and the equity accounts all need to reconcile against the trial balance from the old system.
We prepare a conversion schedule showing every opening figure and its source. That schedule is what makes a later question answerable, whether it comes from your accountant, an auditor, or IRAS.
Debtors
Reconciled at cut-off
Creditors
Reconciled at cut-off
Bank & assets
Tied to the trial balance
A conversion schedule is not a document to file and forget. It is the answer to the first question an auditor or IRAS officer will ask — where did this opening balance come from — and it should be readable years after the migration closes.
Pre-flight checks
Checking the data before anyone relies on it
Before the new ledger goes live, we run a set of checks against the cut-off. Anything that does not agree gets investigated and documented. A discrepancy found during migration is a normal part of the work. A discrepancy found six months later after the old system has been switched off is a different problem entirely.
What gets checked
- Trial balance — new system vs old at cut-off
- Bank balances against statements
- Debtor and creditor listings complete
- GST control account vs last filed return
How disagreements are handled
Every variance is traced to its source transaction or timing difference and written into the migration file before go-live. If a check cannot be cleared cleanly, we say so in writing rather than quietly carrying the number forward.
Parallel month
Running the first parallel month
For the first month after go-live, we keep the new ledger’s figures comparable against the old system’s output. That means reconciling the same period twice and confirming the results agree. It slows the first month down, and it is the reason firms end up trusting the new ledger instead of quietly double-checking every number.
Chart of accounts
Setting up the new chart of accounts
The default chart of accounts in Xero or QuickBooks Online is built for general trading businesses. A professional services firm needs something different.
Service lines
Revenue categories that follow your actual service lines, not a generic trading menu.
Disbursements
A clear split between recoverable disbursements and overhead, so client-matter cost stays visible.
Payroll
Payroll accounts that don’t need manual journals each month to keep CPF and net pay in step.
We rebuild the structure during onboarding using your historical reporting as a guide. Where you want to start reporting by client or practice area, the coding needs to exist from day one, because retrofitting it later means re-coding history.
Boundaries
What stays with your own accountant
Migration does not move your statutory responsibilities. If you have an existing accountant handling your corporate tax filing, GST submissions, or the annual return, they keep those unless you decide otherwise.
- Corporate tax Stays with your existing tax preparer unless you decide otherwise. We coordinate the year-end pack and answer ledger questions.
- GST filings Filed by your appointed accountant. We confirm the opening GST control position they will see, and the last filed return it reconciles to.
- Annual return Stays with your existing accountant. The ledger we keep feeds their filing; it does not replace it.
- Corporate secretarial ACRA matters remain with your appointed corporate secretary. We do not take on that role.
Onboarding
Onboarding checklist and the first month-end
A typical onboarding covers access setup for the platform and bank feeds, agreement on the reporting pack, confirmation of your GST cycle and filing basis, payroll headcount and pay dates, and the naming conventions we will use for clients and suppliers. Most of it happens in the first two weeks.
The first month-end close is the real test. It is usually slower than steady-state closes because we are still learning your transaction patterns. By the third close, the rhythm should be settled.
Timelines
Timelines and what affects them
A straightforward migration from a current, reasonably clean ledger into an empty cloud subscription usually takes two to four weeks. We give an estimate after reviewing the current records, not before.
| Stage | Typical elapsed | What can extend it |
|---|---|---|
| Records review & cut-off | 2–4 days | Records in poor condition; a cut-off that collides with a filing deadline |
| Extraction & conversion schedule | 3–7 days | Several years of history; multiple entities |
| Checks & opening balances agreed | 3–5 days | Unresolved reconciling items on one or more bank accounts |
| Chart of accounts rebuild | 2–4 days | Client-level or practice-area coding that must exist from day one |
| First parallel month | One billing cycle | Unusual transaction patterns in the first period |
If the estimate changes mid-migration because of what the data turns out to look like, we tell you at the point we find out — not at the end.
Where to start
Every due date gets its red line.
Bring us the current ledger and we will read it before we quote anything — the sequence, the cut-off, and what stays with your own accountant. No obligation, no sales pack.
Mon–Fri 9:00 AM – 6:00 PM · Sat 10:00 AM – 1:00 PM · +65 6236 9283
Singapore Cloud Ledger Pte. Ltd.
End of migration & onboarding
Read how we work next