The SaaS Customer Onboarding Process: Start the Data on Day One

Most onboarding plans share five of these stages. The sixth, the data track, is the one they leave out, and it's the one to watch: it starts at signing and runs alongside everything else. Here's what "done" looks like for each.

1. Sales handoff. Done when the onboarding lead knows what was sold, to whom, and what the customer expects to do in month one, without asking the customer to repeat it.
2. The data track, from the day they sign. Done when the customer's records are in your product and someone on their side who knows them has checked them.
3. Kickoff. Done when both sides agree on goals, owners and a target go-live date, in writing. The date gets firm once a sample of their data has loaded and checked out.
4. Setup and configuration. Done when users, roles, SSO and integrations work with the customer's real records in them, not demo data.
5. Training. Done when each team has done its daily job in the product once.
6. Go-live and review. Done when the old system is read-only and you've checked usage at 30 and 90 days.

If you sell a system of record, you've heard some version of this: "We love the product, but we can't move off the old system without losing our historical data."

They're right to worry. A system of record is useless without the record. Nobody can train on a CRM with no contacts or run month-end in an ERP with no open invoices. So setup, training and go-live all wait for the data. And the data waits on the system the customer is leaving, which has no reason to make leaving easy.

Brivity, a real estate CRM platform, lived this. Its target onboarding timeline was 14 to 21 days. Getting from a customer's raw data to an upload took 10 to 12 business days on its own, all done by hand.

“We were spending 5 to 10 hours on a single file doing little clicks here and there to tighten up the data. It just was not scalable as our business grew.”

Yet most onboarding guides give this step a few lines at best. In the five ranking guides we reviewed, none had a section on moving a customer's records out of their old system. Three don't mention importing data at all.

That's a fine plan for a product that starts empty. It's the wrong plan for one that has to hold the customer's records on day one. As I wrote in The Hidden Revenue Killer, migration is the first product experience your customer has. Treat it like a checkbox and it shows.

Don't wait for kickoff to talk about data. The week they sign, book a short data intake call with whoever holds the admin login to the old system. That's often not the person who signed.

You can start even earlier. ERP Advisors Group, an ERP consultancy, starts migration planning while the client is still choosing software. Its reason, about data migration: "We tell our clients it is the wildest variable in the total cost of your implementation."

Give the data track one owner on your side: the onboarding or implementation lead, not an engineer borrowed from the roadmap.

Ask these on the call:

• Which system are you leaving, and which plan or version are you on?
• Which records do you work from every week? Customers, open orders or deals, invoices, cases, documents.
• How many years of history do you report on, and what do you have to keep for legal, tax or contract reasons?
• Who holds the admin login, and when does your contract with the old vendor end?
• What does the export give you? Send us a sample file this week.
• What does it leave out? Check attachments, notes, activity history and custom fields.
• Who on your side will check the data before go-live?

The sample export is the point of the call. It tells you more about your real timeline than any project plan. If it arrives as JSON, our free JSON to CSV converter shows what Excel may change before anyone on either side opens it.

That sample puts the old system into one of three buckets, and each one changes the plan.

Only the first bucket is the easy case the "import data" checkbox assumes. In Rubie's own data, 95% of the source systems we see don't have a clean API or export format that captures all the data a migration needs.

So plan for the second or third bucket by default, and treat a clean export as good luck.

Two bad answers come up at this point. One is "bring everything." The other is "let's just start fresh."

ERP Advisors Group, writing about ERP projects, rejects both. Moving nothing "just isn't workable for a company of any substantial size," because the new system needs its basic records, like customers and vendors, before anyone can do any work. Moving everything is the other trap: "don't kludge up your new ERP with all the data of the past. It is way too painful to cleanse, transform, and validate, with little value to show for it."

Here's the rule I'd use: move what the customer works from and what they're held to.

• Core records. Every customer, contact, vendor, product or location they'll look up in week one.
• Open work. Deals, orders, invoices, cases and tasks that aren't closed.
• The history they report on or must keep. The years in their board deck, and anything an auditor, regulator or contract requires.
• Everything else stays readable, not moved. Keep it where they can still look it up, and write the split into the kickoff notes so nobody reopens it later.

Then clean what moves. Brivity's team put it simply: "We really don't want to move bad data from one place to another." Cleaning on the way in is part of the migration, not an extra.

Before you commit to the go-live date, load a real slice of the customer's data into a test account: a few hundred records across every object, including the ugliest ones you can find.

Then have the customer's admin check records they know by heart: their biggest account, last week's open invoice, the contact with ten years of history. If those look right, sign off and schedule the full load. If they don't, you found the problem in week two, not on go-live day.

Then, and only then, cut over (switch for good): freeze changes in the old system, run the full load, check it again, switch.

Track two numbers for every customer: days from signing to go-live, and days from receiving the customer's data to having it loaded. The second is the one that tells you whether data is your bottleneck.

• Week of signing: handoff notes written, data intake call held, sample export requested, data track owner named.
• Kickoff: goals and owners agreed, go-live date pencilled in, what moves and what stays written down.
• Setup: users, roles and SSO configured, sample load checked by the customer's admin.
• Before go-live: each team trained, full load checked, old system frozen.
• After: usage reviewed at 30 and 90 days, both onboarding numbers logged.

Rubie is an end-to-end data migration platform for customer onboarding. It runs the data track for your onboarding team. It gets a new customer's history out of the system they're leaving, even with no API or clean export (by our numbers, that's most of them), cleans and maps it, puts it in a review queue for approval, and loads it into your product. None of that takes engineering time, consultants or new headcount.

Rubie's own data puts the average reduction in migration timelines at 50 to 90%. Brivity tracked a narrower number: import turnaround, the step that held up its whole onboarding, dropped from 10.6 days to 5.3.

See how Migration Playbooks work, or read the Brivity story.

It's an employee onboarding framework, not a customer one. Talya Bauer's 2010 SHRM Foundation report laid out four C's for new hires: Compliance, Clarification, Culture and Connection. Her later version adds Confidence as the fifth.