Data Migration
Move Systems Without Losing the History
The reason businesses stay on a system they have outgrown is almost never the new system - it is the fear of the move. Ten years of customers, deals, files and notes, and one bad import that nobody notices until an invoice goes to the wrong address. I do the mapping, the cleaning, the pilot, the delta and the cutover, in that order.
Key takeaways
- Field mapping is the whole project. Everything that goes wrong later was a mapping decision nobody wrote down.
- Migrate in three passes: a pilot on a subset, a delta for everything that changed since, then the cutover.
- A CSV export is rarely the migration. Sub-items, files, linked records and update history usually need the API.
- Decide up front what you are deliberately not bringing. Migrating ten years of dead records just moves the mess.
What I build
- Field mapping documented and signed off before anything moves
- Cleaning, de-duplication and normalisation on the way through
- Pilot migration on a real subset, verified by the people who use the data
- Delta migration for records that changed during the project
- Files, attachments, linked records and activity history, not just the table rows
- A reconciliation report: counts and totals on both sides, so you can prove nothing was dropped
Projects I built
How it works
A short scoping call
What hurts today, what you already use, and what "done" looks like.
A written fixed-price quote
Scope, price and timeline in writing, approved before any work starts.
Built in stages, on your real data
You see a working first version early, not a demo at the end.
Handover with documentation and monitoring
You own the code and the data, and a support window follows launch.
Working with me from the US or Europe
- Most of my client work is for companies in the US, UK, Germany, the Netherlands and Australia.
- Calls are in English and scheduled in your time zone. My working day covers most of the European one and the US East Coast morning.
- A fixed price in US dollars, agreed in writing before any work starts.
- Pay me directly, or hire me through Upwork if you prefer to work through a platform.
- You own the code and the data, with documentation and a support window after launch.
Guides on this
Practical guides from real client work.
Custom Software vs Off-the-Shelf: When a Small Business Needs a Custom System
Custom software vs off-the-shelf is rarely about features. I break down when SaaS is right, when you have outgrown it, and a clear build vs buy framework.
From Idea to MVP: How to Build an MVP (And What It Costs)
A practical guide to how to build an MVP: scoping must-haves vs later, realistic MVP development cost and timeline, and how AI now ships your idea in weeks.
Hiring a Developer to Build Your MVP: Freelancer vs Agency vs In-House
Hiring a developer to build your MVP? A practical comparison of freelancer vs agency vs in-house on cost, speed, risk, and control, plus red flags and how to structure the deal.
Signs Your Business Has Outgrown Spreadsheets (Time for a Custom App)
Has your business outgrown spreadsheets? The concrete signs it is time to replace spreadsheets with a custom app, the real cost and timeline to build one, and how AI made it affordable.
No-Code vs Custom Code for Building Your App or MVP
No-code vs custom code for apps: what each is good at, real cost and speed early vs total cost of ownership, the no-code ceiling and lock-in, and when to pick which.
How to Validate Your Idea Before You Build It
How to validate a startup idea before building: why validation saves money, talking to real customers, the smoke test, pre-sales, a manual concierge version, and the signals that justify building.
What Is an MVP, Really? Common Mistakes Founders Make
What is an MVP, really? A clear definition of minimum viable product, what an MVP is not, good vs bad examples, and the most common mistakes founders make.
How to Choose the Right Tech Stack for Your MVP
How to choose a tech stack for your MVP without overthinking it: the principles that matter, a sensible default stack, when to deviate, and what not to optimize for too early.
Is Vibe Coding Production-Ready? A Developer's Honest Take
Is vibe coding production-ready? An honest developer's take on what vibe coding is great at, where it breaks, and a prototype-vs-production checklist.
Frequently asked questions
Can we keep working during the migration?
Yes, and that is exactly why the delta pass exists. The pilot and the bulk load happen while you carry on in the old system, then a final delta catches everything that changed, and only the cutover needs a quiet window - usually hours, not days.
What about Monday.com specifically?
Monday is a common source and a common destination, and it is a good example of why an export is not a migration: boards, items, sub-items, columns, users, files, updates and the links between them each move differently, and the API has usage limits that shape how the run is paced. Treat it as a project, not a download.
How do we know nothing was lost?
A reconciliation report at the end: record counts per entity, financial totals, and a sample of records checked field by field on both sides. If those three agree, you have evidence rather than a feeling. If they do not, you find out before the cutover instead of in six months.
Sources
Official documentation you can verify the claims on this page against.
Let us scope your project
Tell me what you need and I will give you an honest scope, price, and timeline.