Service · Data, ERP and CRM

Move your ERP or CRM data without losing the business behind it.

I map, clean, validate and import the information your business depends on. This isn't copying rows: customers, orders, documents and history have to keep making sense in the new application.

I have a migration pending See the process

ERP · CRM · Excel · SQL
Validation by stages
Remote EU/US

The real problem

A bad migration doesn't show up on day one

The code can be ready and the application look finished. The risk appears when data arrives incomplete, duplicated or without the relationships the business needs.

You don't know the source schema

The old database has tables, fields and rules nobody documented. Copying without understanding them creates incoherent information.

The data is dirty

Duplicates, empty fields, different formats, repeated customers and inconsistent dates that the new app should not inherit as-is.

Relationships are missing

An order without a customer, an invoice without lines or a document without history breaks the logic of the business.

The business can't stop

You need to migrate while still serving customers, and be able to roll back if something doesn't add up.

There is no way to verify the result

Everything looks imported, but nobody knows whether totals, balances or history match the old system.

Documents don't migrate themselves

Invoices, contracts, files and attachments are often left out of the first copy, and they are part of the business.

The approach

First we define what a correct migration means

Before moving a single record, I need to understand which information is critical, how it relates, and what must still be true when it reaches the new application.

From there I build a staged process: inventory, mapping, cleaning, dry run, migration and validation. Each stage leaves evidence of what has been transformed.

The migration doesn't end when the importer stops throwing errors. It ends when you can verify that the data represents the business.

If the source system won't allow data export or you lack authorization to use it, the migration can't be planned reliably. That is checked at the start.

Source inventory: ERP, CRM, spreadsheets, SQL or APIs.
A field-by-field map between source and destination.
Agreed cleaning and normalisation rules.
A dry run before touching production.
Validation with totals, samples and edge cases.
A rollback plan and a migration window.

What's included

The work behind a trustworthy import

I can take the whole process or the part that is blocked. What matters is not separating migration from data design.

Data analysis and database design

The problem: The current structure doesn't represent the business relationships well or won't support expected volume.
What I do: I review the model, tables, keys and constraints before defining the destination.
What changes: A database that doesn't drag the old system's problems along.

Field and entity mapping

The problem: The ERP's names and concepts don't match those of the new application.
What I do: I document which field goes where, what gets transformed and what is discarded, with explicit criteria.
What changes: Fewer improvised decisions and fewer surprises halfway through.

Cleaning and normalisation

The problem: The original data has duplicates, inconsistent formats and values the app won't accept.
What I do: I apply reproducible cleaning rules and leave a report of what changed.
What changes: Usable data with traceable changes.

Import from CSV, Excel, SQL or API

The problem: Information lives in different formats and there is no single way in.
What I do: I build idempotent importers and run them in stages, with logs and error control.
What changes: You can rerun the import without duplicating data.

Documents and files

The problem: Invoices, contracts or attachments live outside the database.
What I do: I map and migrate files, links and metadata, checking they stay attached to their entity.
What changes: The documentary history travels with the data.

Validation and integrity

The problem: There is no objective check that the migration was correct.
What I do: I compare counts, totals, samples and relationships; I document incidents and acceptance criteria.
What changes: You know what was migrated, what wasn't and why.

Who it's for

Cases where migration is the critical piece

If the business depends on historical information, migration is not a last-minute technical detail.

Companies replacing an ERP

You want to leave software that no longer fits and keep customers, orders, invoices and history.

Companies changing CRM

You need to move contacts, opportunities, activities and notes without losing commercial context.

Custom apps already running

You built an internal tool with AI and need to bring in the data your team already uses.

Data spread across systems

Spreadsheets, an old database and an API coexist day to day and need to be unified.

How it works

A staged migration with checks before production

The process is designed so you can see progress and catch problems before data enters the final system.

01
Data inventory
Sources, volumes, formats, permissions and owners.
02
Migration map
Field by field, transformation rules and acceptance criteria.
03
Dry run
Import into a test environment and review the results.
04
Live migration
Controlled execution with logs, an agreed window and rollback.
05
Validation and close
Totals, samples, relationships and documented incidents.

Frequently asked questions

What to clarify before migrating

Can you migrate data from any ERP or CRM?

It depends on the access available. If you can export to CSV/Excel, query the database or use an authorized API, it can be assessed. I don't promise compatibility with any product without reviewing the source first.

How do you avoid losing information during the process?

With a prior inventory, explicit mapping and staged validation. Nothing goes straight to production without a dry run and agreed acceptance criteria.

Can we keep using the old system during the migration?

Usually yes. We define a cutover window and a plan for changes made between the copy and go-live. If the business can't stop, we plan more carefully.

What happens to invoices, contracts and attachments?

They are reviewed separately from the tables. Documents often need path mapping, storage and checks that they stay attached to their customer, order or project.

How do I know the imported data is correct?

Counts, sums, balances, samples and relationships are compared between source and destination. The result is documented, including anything that could not be migrated and why.

Can you connect the new app to the old system?

Yes, if the system offers a stable API or data access. It can be a one-off integration or a sync while both systems coexist.

Do you work with confidential data?

Yes, with minimum access and confidentiality agreements where needed. I don't need full copies on my machine if we can work in a controlled environment.

Can you handle only the import and not the rest of the app?

Yes, provided the destination structure is clear or I can review it. If the data model won't support a reliable migration, I'll tell you before starting.

Contact

Tell me where the data comes from and where it needs to go

You don't need to know the schema. With the source system, approximate volume and destination I can point you in the right direction.

What helps to include

Which system you use now (ERP, CRM, spreadsheets, custom database).
What data you want to migrate and which part is critical.
Approximate number of records or customers.
Which application should receive the data.
Whether you can export it or have API access.

Don't attach exports with personal data or credentials in the first message. First we define the scope and a secure channel.

Related help

If migration is one part of the project

Related service