Migrating your book of business onto a platform you resell

The situation

You have a book of business — twenty, fifty, two hundred clients on something you built or resell — and you've decided to move them onto a different platform, because the margin math stopped working or the vendor's roadmap stopped matching yours.

The hard part isn't the platform evaluation — you can do that in a month. The hard part is that every one of those clients has a working system, someone who champions it internally, and a memory of the last migration you put them through. A migration is a relationship problem wearing a technical costume. The data moves in a weekend; the trust moves over a year, and only if you handle it deliberately.

Sequence by political risk, not by revenue

The instinct is to migrate the biggest account first — prove it at scale, secure the revenue, then the rest is easy. That's usually wrong. Your biggest account has the most stakeholders, the most customizations, and the loudest voice when anything goes sideways.

Go instead for the client with the clearest pain and the lowest political risk: often a mid-sized account where one person owns the relationship, the current system is visibly failing them, and they've already asked when it's getting fixed. They'll forgive rough edges because you're fixing something they complained about. That forgiveness is the budget for migration number one, and you only get it from someone who wanted the change.

Then do a second that looks structurally like the first — you're not proving the platform works, you're building a runbook. The third should be boring. If it still feels bespoke, fix the runbook before touching account four.

Decide what you're deliberately leaving behind

Every legacy system carries dead weight: the report requested in 2019 and never opened again, three custom fields that duplicate each other, the approval step everyone skips manually. Lift-and-shift doubles your maintenance surface on the new platform.

Before you map a field, run a usage pass: which screens got opened last quarter, which custom logic actually fires. Split everything you could rebuild into three piles — rebuild, retire, and ask. The "ask" pile is the useful one; it forces a conversation about what the client actually needs, and that's where a migration turns from an imposition into a review.

Be honest about the retire pile. "We're not carrying this forward, here's why, tell us if we're wrong" is a strong position. Dropping something quietly gets you a furious call in month three.

The data will not map cleanly, and that's normal

Three categories of record:

Clean. Customers, products, open orders. Export, transform, load, reconcile counts.

Lossy. Records where the old model doesn't fit the new one — free-text status fields that must become explicit workflow states, notes fields holding structured data. Write the judgment calls down; you will be asked about them later.

Historical. Closed records, years of attachments, audit history the new system was never going to accept. Consider not migrating these at all — keeping the old system read-only as an archive is cheaper, safer, and more honest than pretending a lossy transformation preserved the record.

Structurally, on FastYoke each client's data lives in its own per-tenant database file, not as rows in a shared table keyed by customer ID. That makes "this client's data is a discrete thing" literally true — the migration target is unambiguous, and if a client leaves, handing their data back is a well-defined act, not an extraction from someone else's shared schema.

Run in parallel, but say how long out loud

Parallel running is the standard safety net, and it's expensive — double data entry, double training, staff who quietly keep using the old system because it's familiar. So be specific about the window. Two to four weeks catches the mismatches that matter; past six weeks you're not de-risking, you're avoiding a decision. Set the cutover date at the start, publish it, and make the old system read-only on that date. A parallel period with no announced end never ends.

It must produce a reconciliation: same period, same numbers, both systems. If they don't match, you find out why before cutover, not during month-end close.

Own the framing and the conversation

Your client should experience this as an upgrade you chose for them, not a vendor change you were forced into. So you make the announcement, not the platform. You run the training. Your name is on the support channel. That's the value of being the provider rather than a referral link — and it cuts both ways, because the blame lands on you too.

Frame the change around what's different for them: the thing they complained about is fixed, here's how that works now, here's who to call. Not "we've re-platformed onto a modern multi-tenant architecture." Nobody was ever reassured by that.

Price the transition honestly

Two failure modes. Eating the cost silently trains the client to think migrations are free, and makes the next one harder. Surprise-billing it after they've agreed to move is how you lose an account you'd technically already migrated. Do it the boring way: quote the migration as a scoped project, separate from the subscription, before anyone commits. If you want to discount it, discount it visibly — a credit the client can see buys more goodwill than the same money never mentioned.

The per-app economics help the pitch. FastYoke's installable apps — CRM Suite, Inventory, Accounting, Project Tracker, Field Service, Forms, the free Logistics core — cost nothing and aren't licensed or metered per app; you pay for platform usage above a free tier. Adding a second or third app isn't a line item to justify, so "we're also giving you inventory" stops being a renegotiation. And because CRM records and Field Service jobs link natively rather than through webhooks, you're consolidating systems, not adding integrations to maintain.

When a client says no

Some will. Usually it's bad timing (mid-audit, mid-acquisition, mid-anything), a feature they can't lose, or a champion personally invested in the current system. Bad timing is a scheduling problem — take the date, don't push. The missing feature deserves an honest evaluation: if it's genuinely absent, migrating them anyway is a churn event with extra steps. The champion is the hardest; give them ownership of the migration rather than arguing them out of their position.

Accept that some accounts stay put. A book that migrates ninety percent cleanly is a success. Ten percent dragged across unwilling is a support burden and a dead reference.

What to watch for

The formal partner program isn't launched. The channel-partner track is early access, and its page says so plainly — it's a placeholder. There's no self-serve signup, and terms, rev-share, and pricing mechanics aren't published. A partner-management dashboard, branded onboarding flows, and a multi-tenant operator console are preview features, not things to plan around today. Two partners are named so far: Pay n Go Systems, the first Channel Partner, in retail, point-of-sale, and food service; and iNetko, the first Strategic Partner, for implementation, support, and consulting. If the track interests you, ask for the first-cohort list at [email protected].

Configuration is real work. You get a workflow engine and apps to configure, not a turnkey vertical product. That's your margin, but budget it as labor.

The audit trail is your cutover evidence. Every state change lands in an append-only event log that's never edited or deleted. When a client asks in month four what happened to a record, that's a query — not an argument about whose export was right.

The takeaway

Pick one client with clear pain and low political risk, scope the migration as a paid project, decide out loud what you're leaving behind, and publish a cutover date. Do that once properly and you have a runbook; three times and you have a practice.

For the wider commercial picture: pricing on how usage meters above the free tier, the marketplace on what your clients can install on day one, and channel partners, where the early-access terms will land when they're published.