Loading articles…
Field notes for building a business that can move without you.
We write from the intersection of operating systems, software, sales, marketing, and leadership—for owners building a more capable company.
Article
Moving your data isn't the hard part. Making it fit is.
Getting your data into a new platform is rarely what goes wrong. Making it fit how your team actually works is. Here's why we run every migration as a fitting, not a transfer.
- Author
Everett Bellingham- Published
- Reading time
- 14 min read
Contents
In brief
- When a business moves to a new platform, getting the data across is rarely what goes wrong. What goes wrong is that it arrives without the context that made it useful, or in a shape that doesn't match how the company actually works.
- Most migrations are run as a one-time transfer. Something gets imported, someone says "everything came across," and the team quietly starts working around the new system.
- We run migrations as a fitting. We capture everything, shape it to your business, import it, try it on real work with your team, and then remove it, reshape it and bring it back in until it fits.
- That loop is designed in from the start, not a rescue plan. Because any import can be cleanly undone and run again, "close enough" never has to be good enough.
- You aren't left to figure it out. The people who do this work sit with your team, run your actual processes on the imported data, and change either the process or the data until both are right. It's part of onboarding.
1. The move that looks finished
You've decided to change platforms. Maybe the tool your team has used for years can't keep up, or the business has outgrown a patchwork of apps. The new system is better. Everyone agrees. The hard part, you're told, is moving your data.
So the data moves. A progress bar fills, the vendor sends a note saying everything came across, and the counts match. Then, over the next few weeks, something quieter happens. A salesperson can't find the template they used every day. A manager opens a procedure and the link to the next step leads to a login page for a system you're paying to leave. Someone builds a spreadsheet "just for now." Within a quarter, the new platform holds your data and the old habits hold your business.
Migrations go wrong in two ways, and they rarely look like failure on the day:
- Loss. The records arrive, but the context that made them useful doesn't. Who owned a document, how one procedure pointed to the next, which version was the draft and which was final, what your team actually called things. None of that shows up in a record count.
- Malformation. Everything is technically there, but in the wrong shape. Categories are flattened into tags. A process that lived as one document arrives as six disconnected fragments. Fields land in the wrong place, or display in a way nobody can read at a glance.
We know this from the inside, because it happened on our own work. Recently we moved a services company's process, SOP and knowledge base platform, years of how that company runs, into Telos. The import was clean by every measure we'd set. Every record and every file arrived, and every relationship between documents was kept.
Then we built the client's migration report and looked closer:
- A category name had arrived as
Training & Coaching Staff, because the old system stored the ampersand in an encoded form and our importer carried it across as text. - Seventeen documents still contained links back to the old platform. They were short links that now led only to its sign-in page.
Neither showed up in any count, and both would have chipped away at the team's trust in the new system. We found them because looking for exactly this kind of thing is part of the process. Finding them didn't mean starting over. We reshaped the affected data and brought it back in.
That's the whole argument of this article in one example. A migration isn't finished when the data arrives. It's finished when your team can do its work with it.
Most migrations never get that far. Industry surveys have found between 38% and 84% of data migration projects running over time or over budget. In one 2017 study of 270 migration practitioners, only 36% of projects stayed on budget and more than half were delayed.[1][2] Those numbers come from large companies with IT departments that track such things. A small or mid-sized business rarely measures its migration at all, so its failures don't show up as overruns. They show up as people quietly going back to the old way.
2. Why migrations usually go wrong
None of this happens because owners are careless or software is bad. It happens because of how migrations are usually set up. Three patterns repeat.
It's treated as a transfer, not a translation. Every platform has its own idea of what a business is made of. One tool thinks in tasks and lists. Another thinks in documents and folders. A third thinks in deals, contacts and pipelines. Moving between them isn't copying files from one drive to another. It's translating from one model of your business to another. A translation done word by word, with no one checking it reads right, comes out technically accurate and practically useless.
The client is left holding the export. The most common migration plan is a CSV file and a help article. The vendor provides an import button, and someone on your team, usually whoever is least busy, which in a growing business means nobody, has to decide how forty columns map onto a system they've used for a week. They make reasonable guesses. Some are wrong, and nobody finds out until the data is in use.
There's no way back, so "close enough" wins. In most migrations an import is a one-way door. Undoing one means deleting records by hand, or living with duplicates, or starting a new account. So once data is in, the pressure is to make do. Small problems get worked around instead of fixed, and every workaround teaches the team that the new system can't be trusted.
The common thread is that migration is planned as an event: a weekend, a cutover, a go-live date. But whether your data fits your business isn't something you can know on cutover day. You find out by doing real work with it. That takes the people who do the work, and it takes the freedom to change what you got wrong.
3. A fitting, not a transfer
A good tailor doesn't take one measurement and hand you a finished suit. They measure, cut, have you try it on, mark what's wrong, adjust, and have you try it on again. Nobody thinks the first fitting failed because the sleeves needed taking in. That's what fittings are for.
We run migrations the same way, in five stages. The last stage loops back, as many times as it takes.
1. Capture everything, change nothing. We take a complete copy of what lives in your current tool: the records, the files attached to them, and the structure around them, such as categories, owners, links between documents and comments. It goes into a secure staging area of its own, separate from both the old system and the new one. Nothing in your current tool is changed, and nothing reaches your new system yet. Before going further, we check the capture against what the source says it holds. If anything didn't come through, we know before it becomes a gap in your new system, not after.
2. Shape it to how you actually work. This is the translation, and it's where most of the judgment lives. Your old tool's categories become collections in the new one. Its roles map onto the teams you really have. Owners are matched to the people on your team. Links between documents are rewritten so they point to each other in the new system, not back to the old one. Some of this is mechanical, and we automate it. Some of it is a decision only you can make, and we bring it to you rather than guessing.
3. Import with a preview first. Before anything is written, we produce a preview of exactly what will happen to every record: created, updated, unchanged, or held back. Anything that needs a decision is held, not forced through. We rehearse the whole import in a test workspace first, so the first time you see your data in the new system, it has already been through one full dress rehearsal.
4. Prove it on real work, together. This is the stage most migrations skip. We sit down with the people who will use the system and run a real business process on the imported data, from start to finish. Section 4 describes what that looks like.
5. Remove, reshape, re-import, and repeat. When the working session shows something doesn't fit, we don't patch it by hand in the live system. We change the shape, either the mapping or the structure, and run the import again. The process is built to be repeated safely. A re-run updates only what actually changed. Anything your team has already edited in the new system is protected and flagged, never overwritten. When it makes more sense to start clean, imported data can be removed and brought back in reshaped. Then we try it on again.
The fifth stage is the reason the other four work. Because any import can be cleanly undone and repeated, nobody has to get the shape right the first time, and nobody has to settle for "close enough". The first fit usually isn't the final one, and saying so out loud is part of the process.
4. What the working session looks like
The working session is simple to describe. After the data is imported, one or two people from your team sit down with one or two of ours. Together, they pick a process the business actually runs, such as processing a warranty claim, onboarding a new hire, or preparing a quote, and walk it through in the new system, from start to finish, using the data that just arrived.
Not a demo and not a tour. A real process, with the real people who run it, on real records.
As the process runs, two kinds of findings come out of it:
- The process needs to change. A step that made sense in the old tool is unnecessary in the new one. A handoff that used to depend on someone remembering can now be explicit. Sometimes the migration shows that the documented process and the actual process had drifted apart years ago.
- The data needs to change. The information is there, but it's in the wrong place, the wrong shape, or displayed in a way that slows people down. A role sits under the wrong team. A procedure that should be one document arrived as several. A link that should open the next step opens nothing.
Each finding gets a decision from the person who owns that work, and each data change goes back through stage 5. Then the process is run again.
In the services-company migration we described above, the decisions were the client's from the start, and they were often ones no importer could have made:
- Roles. Their old system had five job roles. Rather than copy them over as-is, they chose where each one belonged. Sales roles went to the sales team. Operations, warehouse and service roles went to the leadership team they actually report into. The president's role mapped onto the president role that already existed in the new system.
- An untitled draft. One document had no title. We could have imported it with a placeholder name. The client asked us to hold it back instead, because a placeholder would have been noise in a library their team relies on. It was held, and the report says so.
- A rehearsal first. We ran the whole import into a test workspace first. The client opened records at random, confirmed they looked right, and we wiped the rehearsal clean before doing it for real.
None of that is exotic. It's what happens when the people who do the work have a say in how their information arrives, and when someone on our side is accountable for making it happen. Your team isn't asked to configure anything or wrangle an export. Their time goes into showing us how the work really moves and telling us whether it fits.
5. At scale: years of work in ClickUp
A knowledge base is a good first example because the stakes are easy to see: a procedure either reads right or it doesn't. Project-management tools are harder, because so much of what matters lives in structure rather than text.
We've since run this same process for a company moving out of ClickUp, the popular task and project management tool. The scale is a different order: about 83,000 tasks across some 2,200 lists, with 55,000 comments, 51,000 checklist items, 46,000 links between dependent tasks, 220,000 custom field values and nearly 12,000 attached files.
In a tool like ClickUp, the meaning of a task isn't only in the task:
- Custom fields. These are set at the level of the workspace, the space, the folder or the list, and each one means something specific to that team.
- Statuses. These differ from list to list, so "Done" in one place and "Complete" in another may or may not be the same thing.
- Subtasks, dependencies and assignees. These carry who is waiting on whom.
- Comments and attachments. These hold the decisions that were never written anywhere else.
- Time tracked against the work. This is often what billing depends on.
An export that flattens all of that into rows hands you your tasks and loses your business.
So we built the capture stage for it. It walked the whole workspace through ClickUp's own interface, recorded what it found, and checked that against what ClickUp said existed before anything moved. On a workspace that size, a full capture took about a day and a half and made roughly 430,000 requests to ClickUp. The first captures taught us things too. A few early runs stopped partway through, and each one led to a fix in how we capture, before any of the client's data reached their new system. That was the loop doing its job one stage earlier.
Then we rehearsed the whole import in a test workspace. Just under 520,000 records went through. About 491,000 were created, and about 25,000 were held back one at a time, each with a reason someone could act on, instead of being forced in. None failed. Along the way the import was interrupted five times, and each time it picked up exactly where it had stopped, without redoing a single record. When the rehearsal was done, we removed it again, as we do before every real import.
That is what makes the fitting possible at this size. If an import can't be stopped, resumed, inspected and taken back out, nobody can afford to try it on more than once.
6. What we won't promise
A process like this is easy to oversell, so here is what it doesn't do.
- Not everything should move. Years of old records aren't automatically useful context, and importing all of them can bury what matters. Before work begins, we agree on what moves, what stays connected where it is, and what stays behind in the old tool or an archive.
- Not every tool should be replaced. For each tool, the decision is to replace it, connect it, or leave it alone, based on what it does and who depends on it.
- Not every system can be imported automatically. Unsupported formats, poor source data and regulated information are identified early, before they become a commitment we can't keep.
- The first fit won't be perfect. We plan for that. What we promise is that it won't stay wrong: we keep reshaping until your team can do its work with it.
- We won't decide for you. Where your data lands, what gets held back and how your roles map are your calls. We bring you the decisions, with a recommendation, and we do the work once you've decided.
7. Why we do it this way
It would be faster to hand you an import button and a help article. Plenty of platforms do, and the counts would usually match. But a migration isn't measured in records. It's measured by whether, a month later, your team is working in the new system or around it.
Your processes, your SOPs and the way your people talk about the work took years to build. They're the closest thing your business has to its own memory. Moving them is less like moving boxes and more like moving a library: the books matter, but so do the shelves, the order and the notes in the margins. That deserves more than a transfer and a hopeful email.
So we do the work, we bring you the decisions, we try it on real work with the people who'll use it, and we reshape it until it fits. You aren't left to figure it out.
This is part of how every Accelerator OS implementation begins. If you're weighing a move off a tool your business has outgrown, see how implementation works or book a discovery call. We'll look at the system you have today and what it would take to move it well.
[1] Zinstall, "Data Migration Failure Rates", updated October 15, 2026. It compiles the measured surveys: Bloor Research 2007 (84% of Global 2000 data migration projects over time or budget) and 2011 (38%), and Experian and Data Migration Pro 2017 (270 practitioners: 36% on original budget, 54% delayed).
[2] SparxIT, "Legacy Data Migration: Strategy, Steps, Costs & Pitfalls", updated October 15, 2026. It traces the figure to Bloor Research's September 2007 white paper, which found that more than 60% of data migration projects overran on time, budget or both.
