Platform · Solutions

Move your item lists, balances and useful history into the new system, checked.

Data migration brings your item list, customers, vendors, balances and the history worth keeping into the new system, cleaned and checked before anybody goes live. Your own people verify a sample. Once the cut-over date passes, the old software is read-only and nothing is kept in two places.

Share your requirements

What it is

Migration decides whether a new system is used or quietly abandoned, more than the screens do. If a counter has to look up a customer’s credit balance in the old software, the staff keep the old software open. Within a month there are two versions of the truth.

What comes across is agreed first, in writing: masters, opening balances, and how far back the history goes. It is cleaned, loaded, and checked by the people whose numbers they are. Then one date is fixed, and everybody works in one place after it.

What it replaces

What your team uses today.

The module takes over these, one at a time, so nothing has to stop while it is set up.

Copy and paste from sheet to sheet
A private file of cleaned rates
Entering the same bill in both programs

Where it goes wrong today

The problems this is meant to ease.

Old data trusted unchecked

Item lists carry duplicates, blank rates and spellings that differ. Loaded as they are, the mess moves across. The new system starts untrusted.

Balances that will not tie

Customer and vendor balances in the old software differ from the ledger. Nobody finds out until a statement reaches a buyer. Then the call comes.

Systems running side by side

Staff enter in the old software for habit and in the new for the owner. Neither is complete. Totals disagree.

Imports done by whoever has time

Each import is a file edited by hand and pasted in. No record shows what was loaded. Nor does any show what was rejected.

Nobody signs off

The data goes in on trust. When a rate turns out wrong, there is no note of who checked what.

Inside the module

What data migration and import does.

Decided before anything moves

Which lists, which balances and how many years of history are agreed in a short document, so no gap is discovered in month two.

Cleaned on the way in

Duplicate items are merged, dead customers marked, and missing tax IDs and phone numbers listed for somebody to fill in.

Balances that tie

Customer dues, vendor balances and stock are matched to your closing figures, with your accountant agreeing the total before loading.

A trial load first

Everything goes in once as a practice run. Your counter staff search for the customers and items they know, and report what is wrong.

One cut-over date

The old system becomes read-only. Running both for a month sounds safe and is the surest way to end with neither being right.

Imports that keep happening

Imports that repeat, such as a supplier price list, a bank statement or marketplace orders, are set up as imports and not a one-time job.

Where it gets used

What this looks like in a working week.

Illustrative scenarios, written to show the shape of the work. They are not accounts of client systems.

Item list from billing software

A shop exports its item list from the old billing software. Duplicates are flagged. The owner decides which entry stays.

Opening balances for the ledger

The accounts assistant loads customer balances. A tie-out compares the total with the ledger and lists customers whose figures differ.

Trial load check

Counter staff pick a sample of items and customers from the trial load. They mark errors on a list. Fixes are made before the real load.

Cut-over day

The old software turns read only on the agreed date. A late bill goes into the new system. A note lists what stayed behind.

Who touches it

The people who open this every day.

Accounts assistant

Checks the balances against the old trial balance, line by line, before signing off.

Counter or store staff

Look for the items and customers they use daily, and find the mistakes nobody else would.

Owner

Agrees the cut-over date, and holds to it.

How it is set up

From first conversation to daily use.

Decide what moves
List the data you hold and what you want kept. The note settles it. Some data moves, some stays, some is dropped.
Collect the sources
Hand over exports, sheets and old reports. A register returns showing each file, its date and its owner.
Trial load
A cleaned copy goes into a test area. Staff try it. Rejected rows come back with a reason against each.
Verify and tie out
Your own people check a sample and the balances. Each set is signed off by name and date. Nothing moves without it.
Cut over
On the agreed date the old software turns read only. A closing note records what was loaded. It also lists what stayed behind.

Measuring it

How you would know it is working.

Record where you stand before it goes live, so the change is measured against your own figures.

Rows loaded against rows rejected, by import
Opening balances as agreed against as loaded
Data sets verified, with the verifier named
Duplicates found and resolved in the item list
Entries still made in the old software after cut-over

How it fits

It is one part of a system, not an island.

A module earns its place by what it passes to the next one. These are the connections we set up most often.

Your accounting software
Your old billing software
Excel and CSV files
Product management
Customer ledger

Already built in

Products that include it.

Built for you

How we would put it in.

Common questions

Questions owners ask about data migration and import.

Our old vendor will not give us our data. What then?

It happens more often than it should. We work from whatever can be printed or exported, usually reports and PDFs, and rebuild the masters and balances from those. Some of it is retyping, and we say how much before you commit.

Can we run both systems for a month to be safe?

We advise against it. Two systems means two versions of every balance, and staff choosing whichever is easier that day. Pick a date, move, and keep the old one open for looking up history.

How much history should we bring?

Balances always, and a year or two of transactions for most businesses. Older data is better kept as an archive you can open when needed than loaded and slowing everything down.

Who checks that it came across correctly?

Your people, because they are the only ones who know. We start by looking at what your current software can actually export, then your team checks a sample of each list and every opening balance.

Why do migration quotes vary so widely?

Sources, data condition and the history you wish to keep are the levers. Many files in odd formats need more cleaning than a tidy export. Limiting history lowers the work. The quote splits the job into parts once we have studied your files.

What sets the pace of a migration?

How fast your people verify. The first usable release is a trial load of items, customers, vendors and balances for them to check. Each date is fixed in the proposal.

Who needs it most

Businesses that ask for this.

Next to it

Modules that work with it.

Talk to us

Tell us how you handle data migration and import today.

A spreadsheet, a register or another system: say which, and we will tell you plainly what is worth changing.

What happens after you share your requirements

A senior engineer reads your answers. Nobody phones first.
Within one business day you get a written note: what we understood, what we would start with, and the questions we still have.
If it fits, a proposal follows with the order of work, what we need from you and what you receive at each step.
No call is booked and nothing is paid until you have read the note. Your details stay with us.

Start with your requirements

Seven short steps that tell us what you need. A senior engineer reads them before anyone gets in touch.