Do I need to fully clean my data before approaching a development team?

No, but you should complete the audit and field-definition steps before scoping begins. A development team needs to understand your data structure to scope the project accurately. Full cleaning can happen in parallel with early build phases, provided the structure is agreed upfront. Arriving with no documentation at all will slow scoping down and may mean your quote is based on assumptions that turn out to be wrong.

What if our data is in a legacy system we cannot easily export from?

This is common in UK businesses running older ERP, CRM, or bespoke systems. Start by checking whether the system has a built-in export function, even a basic CSV export. If not, your IT provider or the original software vendor may be able to provide a data extract. In some cases, a development team can write a one-off extraction script. Flag this early in your project conversations — it affects both timeline and cost.

How does UK GDPR affect data migration for a custom app build?

If you are migrating personal data (customer names, contact details, employee information) into a new system, or sharing that data with an external development partner during the build, UK GDPR obligations apply. You should have a data processing agreement in place with any third party who handles the data. You should also review whether you need to update your privacy notice to reflect the new system. This is not a blocker, but it needs to be addressed before any data transfer happens.

Should we migrate all historical data or just recent records?

In most cases, migrating a defined window of recent, active records on launch day and archiving older history separately is the right approach. Full historical migrations add complexity and cost, and most day-to-day operations do not need records from five or ten years ago to be live in the new app. Discuss this explicitly with your development partner during scoping and agree a clear cutoff date.

What is the biggest mistake businesses make with data before a custom build?

Assuming it will be sorted out during the project. Data problems discovered mid-build are significantly more expensive to resolve than those identified before scoping. The second most common mistake is not documenting business rules — the informal logic your team applies every day without thinking. If those rules are not captured before build, they will not be in the app, and your team will revert to manual workarounds immediately after launch.

How to Prepare Your Business Data Before a Custom App Build

To prepare your business data before a custom app build, you need to complete four things before development starts: audit every data source you currently use, agree on a single set of field definitions, clean and deduplicate your records, and document any business rules that live only in someone's head. Skipping any of these steps is the single most common reason UK SME software projects run late or cost more than scoped.

Warning

Data readiness is consistently underestimated. Many project delays on custom builds are not caused by difficult code — they are caused by data that arrives mid-project in an unexpected format, forcing the development team to stop and redesign core logic.

Why Data Preparation Matters More Than Most Teams Expect

When a development team scopes a custom app, they make assumptions about your data: how it is structured, how consistent it is, and how much of the business logic is encoded in the data versus applied manually each time. If those assumptions turn out to be wrong after build begins, the cost is not just a one-off fix. It can mean redesigning the data model, rewriting imports, and re-testing features that were already signed off.

For UK SMEs, the underlying data is often spread across Excel sheets passed between colleagues, a CRM export from a system the business outgrew, a legacy Access database, or a mix of all three. None of that is unusual. The problem only starts when the data's inconsistencies are discovered late, rather than documented early.

Step-by-Step: How to Prepare Your Business Data

Identify every active data source. List every place your business currently stores data that the new app will need to read, import, or replace. This includes spreadsheets on shared drives, exports from off-the-shelf tools, email threads where decisions are recorded, and anything your team maintains manually. The goal is a complete map, not a polished one.
Run a data audit on each source. For each data source, record: how many rows or records it contains, the date range it covers, who owns it, how often it is updated, and whether it is the master copy or a derivative. A simple spreadsheet is fine for this. You are looking for surprises — a 'live' file that has not been touched in two years, or three files that are supposed to be the same list but are not.
Agree on field definitions and naming conventions. This is where most projects stumble. If one spreadsheet calls a field 'Company Name' and another calls it 'Client' and a third calls it 'Account', your development team cannot safely merge them without a decision from you. Go through every field that the new app will store and agree on a canonical name, data type (text, number, date, yes/no), and whether it is required or optional.
Deduplicate and clean your records. Remove exact duplicate rows first, then look for near-duplicates — the same customer entered twice with slightly different spellings, or the same product listed under two codes. Tools like Excel's Power Query, Google Sheets, or OpenRefine can help at this stage. The important thing is to make decisions about which record is canonical before handing data over, not to leave it for the development team to guess.
Surface and document your business rules. Business rules are the logic your team applies when working with data that is not written down anywhere. Examples: 'We never archive a customer record if they have an open invoice', or 'If a job is marked complete but not invoiced, it stays in the active queue'. These rules must live in the app. If they are not documented before build, they will be discovered during user acceptance testing, at the worst possible moment.
Decide what historical data you actually need. Migrating ten years of records when the app only needs the last two years adds risk, cost, and complexity. Have a clear conversation with your development partner about the minimum viable history the app needs on launch day. Archiving old records separately is often the right call.
Prepare a sample data set for development. Your development team will need realistic data to build and test against. Create a sample of around 50 to 100 anonymised or dummy records that represent the full range of your real data — including edge cases and messy ones. A clean, perfect sample produces a tool that works beautifully in testing and fails on your real data on day one.

Common Data Problems Found in UK SME Projects

Problem	Where It Usually Comes From	Impact on Build
Inconsistent date formats (e.g. 01/07/26 vs July 1 2026)	Multiple people entering data over time	Date sorting and filtering logic breaks during testing
Free-text fields used for structured data	No enforced validation in legacy tools	Requires manual classification before import; delays data model finalisation
Duplicate customer or product records	Mergers, manual re-entry, multiple systems	Reporting is wrong until resolved; can corrupt live data on first import
Business rules applied only in someone's head	Long-tenured staff, undocumented processes	Features get built incorrectly and only caught in UAT
No clear 'master' record when sources conflict	Multiple teams maintaining separate copies	Development team cannot proceed without a business decision from you
Personally identifiable information in unexpected fields	Freeform notes columns, email threads	UK GDPR obligations apply; needs a legal review before migration

Tip

UK GDPR applies to data you migrate into a new system just as much as data you collect fresh. If your legacy data contains personal information — customer names, contact details, employee records — check with your data protection lead before handing any files to an external development partner. A data processing agreement should be in place before any transfer.

What to Hand to Your Development Team

A well-prepared data pack saves your development team significant time during scoping and sprint planning. Aim to provide the following before your first technical session:

A data source inventory (one row per source, with owner, format, record count, and last updated date)
A field glossary (agreed names, data types, and required/optional status for every field the app will store)
A documented list of business rules that affect how data should be read, updated, or displayed
A cleaned, anonymised sample data set covering real edge cases
A clear statement of which historical records must be migrated versus archived or discarded
A note on any fields that contain personal data and confirmation that a data processing agreement is in place

How Long Does Data Preparation Take?

For a typical UK SME with three to five data sources and a few years of history, a thorough data preparation exercise takes one to three weeks of focused internal effort. That estimate assumes one person is accountable for coordinating it and that decisions about field definitions and business rules can be made quickly. If the data is spread across departments with no single owner, or if legacy systems require IT involvement to export, the timeline extends.

This is time well spent. Projects that start with clean, documented data consistently move faster through build, produce fewer surprises in testing, and require less rework post-launch. The development team can focus on building the tool, not diagnosing your data.

When to Ask Your Development Partner for Help

Data preparation is primarily a business task, not a technical one. Only you and your team know what the data represents and what the rules are. That said, a good development partner can help you with the technical side: writing scripts to extract data from legacy systems, identifying structural inconsistencies you might not spot in a manual review, and advising on the data model before you do the cleanup work. If your data situation is complex, raise it early in scoping rather than hoping it resolves itself.

Note

If you are about to start a custom app project and are unsure how complex your data situation is, bring a sample export to your first technical conversation. A development team worth working with will be able to tell you within an hour what the likely challenges are.