Switching without losing a season

Migration 10 min read

Firms stay on software they dislike for years, and the reason is almost never the software. It is the migration — a vague, unbounded risk sitting between the current situation and a better one, which is exactly the shape of problem organizations are worst at evaluating.

It is worth being specific about what the risk actually is, because most of it is smaller than it feels and one part of it is larger.

The one rule

Never migrate during work you cannot afford to redo.

That is the whole rule. If something goes wrong in May, you re-key a week of work items and lose two days. If the same thing goes wrong on March 20, you are reconstructing the state of forty in-flight returns during the week they are due, and that is how a migration becomes a story people tell at conferences.

For most US firms the windows are May through July, or late September through November. The window that looks tempting and is not: January. The new system is fresh, the season is about to start, everyone is paying attention — and you have chosen to have your staff learning new software during the eight weeks they have the least tolerance for it.

What to move, and what to deliberately leave

The instinct is to bring everything. It is usually wrong, and it is the main reason migrations take three months instead of three weeks.

Move

• Active clients. Contacts, entity details, identifiers, service enrollments. This is the core and it has to be right.
• Open work. Everything in flight, with its status and owner.
• Current-year and prior-year documents. What staff will reach for in the next twelve months.
• Portal users. So clients are not re-invited from scratch.

Leave

• Inactive clients. If they return, add them then. Migrating four hundred dormant records to preserve the twelve who come back is a bad trade.
• Completed work history. Useful for reporting, rarely worth the migration cost. Export it and keep the file.
• Documents older than two or three years. Archive them to storage. Note the interaction with your retention policy here: the Safeguards Rule expects secure disposal of customer information no longer needed, so a migration is a natural moment to actually delete what should have been deleted.
• Every internal note ever written. Move the ones attached to active clients. The rest are archaeology.

A six-week sequence

Weeks 1–2: shape and load

Configure the new system to match how the firm actually works — work types, statuses, services, document categories, roles and permissions. Do this before importing anything, because import decisions depend on it. Then load clients and validate a sample by hand: pick twenty records across your different client types and check every field.

Resist the urge to redesign your processes at the same time. Migrate the process you have; improve it in month three. Two changes at once means you cannot tell which one caused the problem.

Weeks 3–4: parallel, with one team

Pick two or three staff and have them work entirely in the new system while everyone else continues as before. Not everyone in parallel — that means everything is done twice and nothing is done properly. A small group working exclusively in the new system finds the real problems; a large group working in both finds only the annoyances.

This is when you discover the thing that always gets discovered: some process nobody documented depends on a quirk of the old system. Better now than in week six.

Week 5: documents and portal

Move documents, then invite clients to the new portal. Do the client invitations as a deliberate communication, not a system-generated email that arrives with no context. A short note from the firm — what is changing, what they need to do, when — moves activation rates substantially.

Stagger the invitations rather than sending four hundred at once. If something is wrong with the flow, you would rather learn it from the first fifty.

Week 6: cut over

Set a date, make the old system read-only, and mean it. A migration with no cutover date runs both systems indefinitely, which is worse than either — the record is split, nobody knows which one is authoritative, and the eventual forced cutover happens at the worst possible moment.

Keep the old system readable for six months. Then export and cancel.

The three things that actually go wrong

Identifiers arrive mangled

SSNs and FEINs exported through a spreadsheet lose leading zeros, get reformatted as numbers, or arrive in scientific notation. Always check identifiers specifically after import, and check the ones beginning with a zero first.

Nobody owns the migration

If it belongs to everybody it belongs to nobody, and it stalls in week three. One named person, with explicit time allocated. Not "as well as their normal work" — that is how six weeks becomes six months.

Training happens once, at the start

A single session before anyone has used the system teaches almost nothing, because people have no context for the answers. A short session at the start, then a second one after two weeks of real use, is worth several times as much — the second session is when people actually have questions.

What Kveldo does to make this easier

Migration help is included, not a professional-services line item — coming from another practice management tool or portal, our team helps you move on your first day at no charge. Provisioning creates your organization with a complete independent copy of every configurable list, so you are shaping your own work types and statuses from a working baseline rather than an empty screen.

And on the other side of the question: your data stays exportable. Every grid in Kveldo exports to CSV or XLSX, from every tab of the client record, without a support ticket and without a fee. We would rather earn the renewal than hold the data.

Talk to us about a migration →
Read next: per-seat vs. per-module pricing →