Moving Your Business Data Into a New Custom System

Once the decision to build a new custom business system is made, most of the attention goes to what the new system will do — the screens, the workflows, the reports. What often gets left until the last minute is what happens to everything already sitting in spreadsheets, an old off-the-shelf tool, or a system that's being replaced: years of customer records, stock counts, past orders and notes. Moving that data across properly is not automatic, and it's one of the most common places a system launch goes wrong. This guide walks through what actually needs to migrate, a worked example of what that looks like for a fairly ordinary customer list, and how to tell a migration plan is solid before you sign off on it.

Why data migration is often the part nobody plans for

A new system's screens and workflows are visible from the first demo, so they get scoped, discussed and signed off early. The data behind them tends to get treated as an afterthought — "we'll just export the old spreadsheet" — until the export turns out to be three different spreadsheets kept by three different staff, none of which quite agree with each other. Planning for data migration at the same time the system itself is scoped, rather than the week before go-live, is what actually prevents this.

The cost of leaving it late isn't just stress in the final week. A migration discovered too close to go-live gets rushed, and a rushed migration is exactly where duplicate customers, dropped records and malformed dates slip through unnoticed — right before the business starts depending on that data every day.

What actually needs to move — and what doesn't

Not everything in an old spreadsheet or system deserves a place in the new one. Active customers, current stock levels and open orders clearly need to migrate; a decade of cancelled orders or discontinued products usually doesn't, and dragging it all in just adds noise a new system has to carry forward. Deciding what's active, what's historical-but-worth-keeping-for-reference, and what can simply be archived as a read-only export is a judgement call worth making deliberately rather than by default.

Cleaning up before you move

Data that's accumulated over years in spreadsheets or an ageing system is rarely clean: the same customer entered twice with slightly different spellings, dates typed in three different formats, required fields left blank because the old tool didn't enforce them. Migrating that as-is just moves the mess somewhere new — a new system will happily import duplicate customers or malformed dates, and then every report built on top of that data quietly inherits the error. Cleaning up duplicates, standardising formats and filling in genuinely required fields before migration is slower up front but far cheaper than fixing it after staff are relying on the new system.

• Duplicate customers or products. The same person or item entered more than once, usually with a slightly different spelling, phone number or SKU each time.
• Inconsistent date and number formats. Dates typed as DD/MM/YYYY in one row and MM/DD/YYYY in another, or phone numbers with and without the country code.
• Blank required fields. A field the old spreadsheet never enforced, such as a postcode or category, left empty on a meaningful share of rows.
• Free-text fields standing in for structured data. A "notes" column quietly holding information — a customer's preferred branch, a discount tier — that the new system actually needs as its own field.

Mapping old fields to the new system's structure

An old spreadsheet's "Customer Name" column and a new system's customer record rarely line up field for field — the new system might split name into first and last, add a required field the old one never had, or store phone numbers in a different format. Mapping each old field to where it belongs in the new structure, and deciding what to do with anything that doesn't have an obvious home, is what makes an import actually usable rather than a pile of data sitting in the wrong places.

Three situations come up in almost every mapping exercise: an old field with no equivalent in the new system (decide whether it's worth keeping as a custom field or safe to drop), a new required field the old data never captured (decide on a sensible default or flag it for manual follow-up), and one old field that needs to split into several new ones, such as a single "Address" column becoming street, city, state and postcode. None of these are hard problems on their own, but they need a decision made for every field, not discovered one at a time during the import.

A worked example: migrating a customer list with three years of mess

Picture a fairly ordinary retail business: 1,400 customer records spread across two spreadsheets kept by different staff, plus a paper-based reward card scheme nobody ever digitised. Here's roughly what a careful migration of that list looks like in practice:

None of this is unusual — it's a fairly ordinary result for data that's accumulated over a few years across more than one spreadsheet. Catching the duplicates and formatting issues during the pilot, rather than after staff are relying on the new system day to day, is what keeps a problem like this from quietly becoming the new system's problem too.

Migration sources compared: what each one actually needs

Running a pilot before the full cutover

Migrating everything in one pass and hoping it worked is how small mapping errors turn into a business-wide problem. A safer approach is a pilot migration: a small, representative batch of records — a handful of customers, a slice of the product catalogue — moved first and checked field by field against the original source. Any mismatches show up while they're still easy to fix, before the same mistake gets repeated across every record in the full data set.

A useful pilot batch is deliberately varied rather than just the first fifty rows in the file: it should include at least one record from each branch or category, one with unusual characters in the name, one with a blank optional field, and one that was flagged as a likely duplicate. A pilot made only of tidy, typical records won't surface the edge cases that cause problems later.

Keeping a safety net through cutover

Even a carefully tested migration benefits from a fallback. Keeping the old system or spreadsheet accessible in a read-only state for a period after go-live means that if a record looks wrong in the new system, staff can check it against the original rather than guessing. Most businesses only retire the old system once the new one has run cleanly through at least a full business cycle — a month-end close, a stock count, a busy sales period — with no data questions left unanswered.

This period is also when staff naturally discover the gaps a pilot batch didn't catch — an unusual order type, a customer with two accounts under different spellings — because they're using the full, real data set for the first time. Treating the first business cycle as a verification period, not just a formality, is what turns an apparently successful migration into one that's actually trusted.

How to tell a migration plan is solid before you sign off

• Ask for the pilot batch size and what gets checked. A plan that moves straight to a full import with no pilot batch is skipping the step that catches mapping errors early.
• Ask what counts as "done" for cleanup. "We'll clean it up" means little without a definition — duplicates found and merged, dates standardised, required fields filled are concrete, checkable outcomes.
• Ask who decides what's archived versus migrated. Someone on your side should own that judgement call; a developer guessing which records still matter to the business is a recipe for losing something useful.
• Ask how long the old system stays accessible read-only after go-live. A plan with no stated fallback period is assuming the migration will be perfect, which is optimistic for any data set with real history behind it.

Common mistakes

• Treating migration as a simple export-and-import step. Real data from more than a few months of use almost always needs cleaning and mapping first, not just moving.
• Migrating everything, including years of dead records. Dragging in a decade of cancelled orders or discontinued products just adds noise the new system has to carry forward.
• Skipping the pilot batch. A full import with no small test run first means mapping errors get repeated across every record before anyone notices.
• Retiring the old system the day the new one launches. Without a read-only fallback, staff have nothing to check a questionable record against during the most error-prone early weeks.
• Not naming one person to own data decisions. Decisions about what's active, what's archived and what's simply wrong need one accountable owner on the business side, not a group guess.
• Assuming the new system's fields match the old ones exactly. They rarely do — a mapping exercise is required even when both systems seem to track "the same" information.

Where Gotka Technologies fits

Working out what needs to migrate, cleaning it up, mapping it to the new structure and testing it before cutover is scoping work Gotka does as part of building the system itself, not a separate project bolted on afterward. Gotka's App & System Development service quotes business systems with integrations from an indicative RM12,000, confirmed by written quote once the scope — including how much existing data needs to move — is known. If you're still deciding whether a custom build is the right call in the first place, see signs your business has outgrown spreadsheets. Whatever the new system runs on still needs somewhere reliable to live; Gotka's Cloud Hosting on LiteSpeed servers covers that alongside the rest of a growing business's website and email.

Key terms used in this guide

• Data migration: moving existing records from spreadsheets or an old system into a new system's structure.
• Pilot migration: a small, representative batch of records moved and verified first, before the full data set is migrated.
• Field mapping: matching each column or field in the old data to where it belongs in the new system's structure.
• De-duplication: finding and merging records that represent the same customer, product or order entered more than once.
• Cutover: the point at which a business switches from the old system to the new one for day-to-day work.
• Read-only safety net: keeping the old system or spreadsheet accessible, but not editable, for a period after cutover.
• Legacy data: the records that exist in the old spreadsheet or system before migration begins.
• Source system: the spreadsheet, old software or paper records a migration pulls data from.