Migration as an Operations Project: Moving a Team to New Coaching Software Without Losing a Week

The decision to change platform has been made, argued over, and signed off. What sits in front of the team now is the part that loses weeks when it is done badly: the migration itself. For a multi-coach business, moving software is an operations project with four phases, and running it as a project is the difference between a team coaching out of the new system by the fortnight's end and a business discovering in month two that its history never arrived. This page is that project plan, at team scale, for a migration that is already decided.

The decision itself is not relitigated here. Whether the platform is the constraint at all is the subject of our guide to when a coaching business outgrows its software, which this page assumes has been read and answered. What follows is execution: readiness, staff, clients, cutover, review.

How do you migrate a coaching team to new software?

Run the switch as four phases over two to three weeks: readiness, where every data source is inventoried and the vendor's import team receives it; staff, where coaches are trained before the cutover, not after; clients, where the communication tells everyone what changes for them; and cutover, where the new system runs parallel, goes live, and is reviewed in its first week. A concierge migration collapses the readiness and cutover load, but the phases still hold.

Phase one: readiness, or what actually transfers

The readiness phase is an inventory, and its one rule is that everything the business holds gets counted as either inside the platform or outside it. Client records, programs, exercise libraries, check-in history, billing state: if these live in the current platform, they travel. What lives in spreadsheets, chat threads, and personal notebooks does not travel by itself, and it is where the real migration hours sit. The honest readiness output is that list, named per source, with an owner for each.

What the vendor does with the inside-platform data depends on the migration being concierge. The documented shape of ours is described in the concierge migration term: the vendor's team imports clients, programs, exercises and history, maps custom exercises one-to-one, rebuilds the top programs, and runs a dry run before any client sees the new system. The dry run is the phase's real event, because it is where transfer assumptions get tested against actual data rather than assumed by both sides. Solo migrations typically run about seven days from kickoff, and teams with more custom programs run ten to fourteen; those are this platform's documented commitments, not industry figures, and your vendor's timeline is theirs to state.

Phase two: staff, and the training that has to precede the cutover

The most common team-scale migration failure is sequencing: coaches are asked to serve clients from a system they met that morning. Training lands before the cutover, on the migrated data, in the workspace the team will actually use, and every coach completes their first program build and their first check-in return in the new system while the old one is still available.

The parallel-running window that follows is what makes this phase safe. Both systems run for a short overlap; the coaches work daily in the new one, nobody deletes anything, and the comparison is honest rather than nostalgic. The window also surfaces the data gaps a dry run missed, while losing a week still costs nothing permanent. What does not belong in training is blank-slate discovery: the standard the team coaches to is the same before and after, and coaches should meet the new system as a change of tools, not a change of method.

Phase three: clients, and the fragile fortnight

A migration's real risk concentrates in one place: the clients, exactly when the business is asking them to re-download an app and trust that their history came with them. The communication phase is short and deliberate, and it says three things once: what is changing for you, what does not change, and what to do on day one.

What does not change carries the message. The client's program, history and coach stay; the brand on the app stays, because the migration's endpoint is the client logging into a branded app with their history intact, which is the outcome the concierge process exists to protect. The invite to the new app follows a sequence, but the sequence is a product event rather than a writing exercise: when the new platform's client invitations go out, the history is already there to greet them. A migration that invites clients before their data is confirmed is testing the relationship at its most fragile point to save the vendor a day.

Phase four: cutover, parallel running and the first-week review

The cutover day is scheduled, not discovered: the date the old system stops taking new entries, the date the client invitations go out, and the date the coaches' daily work moves entirely, in that order. After the switch, the first-week review closes the project, and it reads five things against the readiness inventory:

• Every client on the roster has a live record with history in the new system.
• Every coach has built and delivered from the new system, not alongside it.
• The first scheduled check-ins in the new system have been returned, against the unchanged standard.
• Billing and scheduling ran without a gap in coverage across the switch.
• Anything outside the old platform, the spreadsheets above all, has been folded into the shared record, and the old system is retired rather than kept warm as a shadow database.

The first-week review is also where the migration pays its forward dividend honestly stated. A migration consolidates the data that the rest of the business runs on: per-coach assignment, the utilisation behind the capacity plan, the tenure arithmetic in the forecasts. If those margins were spreadsheets before the migration, the new system is where they become pullable, and the first-week review should confirm it rather than assume it.

The execution timeline, phase by phase

The phases below assume a multi-coach business with a concierge migration in scope, and the durations follow the documented commitments: roughly seven days from kickoff for a smaller roster, ten to fourteen for a team with more custom programs. Extend the columns for a bigger data estate; the sequence does not change.

Phase	Owner	Output before the phase closes
1. Readiness	Owner or manager, with the vendor's migration team	Data inventory, owners named, dry run completed against real data
2. Staff	Manager	Every coach has built and delivered once in the new system, on migrated data
3. Clients	Owner	Communication sent; invitations scheduled after data confirmation
4. Cutover	Manager	Old system frozen for new entries; parallel window closed; first-week review checklist passed

What this page deliberately does not do

It does not re-run the decision. The platform comparisons live in their own places, dated and maintained: the shortlist for a business ready to scale and the one for multi-coach studios cover the selection question with dated pricing, and this page links rather than competes. It does not price the platforms here either, because pricing belongs with the dated sources and with the plan structures that frame it, which sit on our pricing page. And it does not walk a solo coach through leaving their notes app, which is a different project with a smaller blast radius. What critics of platform changes get right is the risk; what this page adds is the order of operations that manages it.

The demo conversation, when the plan is real

A migration plan is at its most honest as a set of questions for a vendor: what transfers, what does not, what the dry run covers, and what the timeline commitment is in writing. For the platform this site sells, those questions are answered on the record, and the concierge process is included in the plan rather than sold as a setup fee. When the decision is made and the phases are in front of you, book a 30-minute demo and bring the readiness inventory, because the honest migration plan, with real data on the table, is the strongest review a platform decision can get.

Frequently asked questions

How long does a team migration to new coaching software take?

Documented commitments for a concierge migration run about seven days for a smaller roster and ten to fourteen for a team with more custom programs, from kickoff to coaching in the new system. The project plan around those commitments, staff training, client communication and the parallel-running window, is what keeps the fortnight from stretching into a lost month.

What transfers when a coaching team changes platform?

Whatever the current platform holds: client records, programs, custom exercise libraries, check-in history and billing state, imported by the vendor's team in a concierge migration and mapped one-to-one where possible. What lives outside the platform, in spreadsheets and private notes, transfers only through the readiness inventory, which is why the inventory comes first.

Do coaches need to be trained before or after the cutover?

Before, on migrated data, and the difference is the whole risk case. A coach who has built a program and returned a check-in in the new system before clients arrive meets the cutover as a tool change. Training after the cutover asks the team to learn in front of the clients at the exact moment the business is most fragile.

What is the first-week review after a migration?

A five-point read against the readiness inventory: every client live with history, every coach delivering from the new system, first check-ins returned against the unchanged standard, billing and scheduling without a coverage gap, and the outside-the-platform data folded into the record. Passing it is what separates a migrated business from a migrated database.

The timelines and phase outputs in this article describe the documented concierge migration process for the platform this site sells, along with scenario structures that apply to any vendor's plan. Confirm what any migration transfers, yours included, against real data before the cutover. This article is a guide for your own decisions, not financial advice.