All articles

SaaS Operations

SaaS implementation: a step-by-step rollout plan for business teams

A six-phase plan to roll out a SaaS product, from requirements to adoption metrics, with a RACI table, a go-live checklist and the usual failure points.

By Published

Isometric 3D illustration of a steel blue moving box with its flaps half open, resting on a white round stand, on a pale grey background.

Your company has signed for a new SaaS product, the contract start date is fixed, and you have been told to “get everyone on it”. You need a plan that turns a login page into a tool people use, without losing data on the way. A SaaS implementation is that plan: six phases, from writing down what the tool must do to measuring whether people use it.

The vendor runs the servers, so implementation is not about installing software. It is about configuration, data, connections and people. Those four are yours, whatever the contract says. If the split between what the vendor runs and what you run is new to you, start with What is SaaS? and SaaS in cloud computing.

Implementation in plain terms

Think of it like moving into a furnished apartment. The landlord owns the building, the plumbing and the furniture. You still have to decide which room is for what, carry your boxes in, label them, get the internet connected and show your family where things are. An apartment full of unopened boxes is not a home, however good the building.

In SaaS terms, the building is the vendor’s product. Your boxes are your data. The internet connection is your integrations. Showing the family around is training. Implementation ends when people live in the new place, not when the keys change hands.

The six phases

Each phase ends with a written output. If a phase has no output, it did not happen.

  1. Requirements. List the processes the tool must support, in the order people do them today. Mark each as required, useful or later. Output: a requirements list signed by the business owner.
  2. Configuration. Set up the product to match those processes: fields, workflows, roles, permissions and naming. Change your process before you customize the product, where the product’s default is reasonable. Output: a configuration record, so the next admin knows what was changed and why.
  3. Data migration. Export from the old system, clean, map each field to the new one, test-import a sample, fix, then import everything. Output: a reconciliation report (records exported against records imported).
  4. Integrations. Connect identity first: single sign-on (SSO), so people log in with their company account, and user provisioning. SCIM (System for Cross-domain Identity Management), an IETF protocol published as RFC 7644 in September 2015, lets your identity provider create and remove accounts automatically. Then connect the tools that feed or read the new system. Output: an integration list with owners.
  5. Training. Train by role, on the tasks each role does every week, with the company’s real data. Output: a short guide per role and a list of who attended.
  6. Adoption. Measure use after go-live and act on it. Output: a 30-day and a 90-day adoption report.

Who does what: a RACI table

A RACI table assigns one role per task: Responsible (does the work), Accountable (owns the result, one person only), Consulted (asked before) and Informed (told after). The table below is a starting point for a mid-size rollout. Adjust the roles to your company.

Task Business owner Project lead IT / admin Vendor
Requirements list A R C C
Configuration C A R C
Data migration I A R C
SSO and provisioning I C A, R C
Training C A I R
Adoption report A R C I

Two rules make the table useful. Only one person is accountable for each row. And the vendor is never accountable: the contract makes the vendor responsible for its service, not for your rollout.

Worked example: migration effort and unused seats

Example: a labeled hypothetical. A company moves 48,000 customer records into a new CRM and buys 120 seats at $30 per seat per month.

Migration. A test import of the full file rejects 4% of records (missing required fields, bad dates, duplicates).

  • Records to fix: 48,000 x 4% = 1,920.
  • At 2 minutes per record: 1,920 x 2 = 3,840 minutes.
  • In hours: 3,840 / 60 = 64 hours, or eight working days of 8 hours for one person.

That is eight days nobody put in the plan. A sample import of 500 records in phase 3 would have shown the 4% rate before the go-live date was set.

Adoption. Thirty days after go-live, 78 of the 120 licensed users were active in a given week.

Measure Calculation Result
Weekly active rate 78 / 120 65%
Inactive seats 120 - 78 42
Monthly cost of inactive seats 42 x $30 $1,260
Yearly cost of inactive seats $1,260 x 12 $15,120

The $15,120 is the cost of a rollout that stopped at go-live. Follow up with each inactive user’s manager before the renewal date, and reduce the seat count if the contract allows it. For how per-seat contracts are priced, see SaaS pricing models.

Go-live checklist

  • The requirements list is signed and every required item is configured and tested.
  • A full test import ran, and the reconciliation report shows exported and imported counts that match, or explains each difference.
  • The old system is set to read-only from the cutover date, so nobody writes to two places.
  • SSO works for every user group, and leaving staff lose access through provisioning, not by hand.
  • Every integration on the list has been tested with real records and has a named owner.
  • Each role has a one-page guide and a named person to ask in the first two weeks.
  • Admin rights are limited to the people who need them, and at least two people hold them.
  • An export of the new system’s data has been run and opened, so you know your exit works.
  • The 30-day adoption measure and its target are written down before go-live.

Common mistakes

  1. Recreating the old system inside the new one. Every old custom field and workaround is copied across, and the new tool becomes as hard to use as the old one. Why it happens: it feels safer to change nothing. Instead: start from the product’s defaults and add a custom field only when a requirement needs it.
  2. Migrating data without a sample test. The first full import fails on the night before go-live. Why it happens: migration is planned as one step. Instead: import a sample early, measure the rejection rate and budget the fixing time, as in the example.
  3. Training on features instead of tasks. People sit through a tour of every screen and remember none of it. Why it happens: the vendor’s standard training is feature-based. Instead: train each role on the five tasks it does every week, with its own data.
  4. Declaring success at go-live. Logins on day one say nothing about week six. Why it happens: the project team moves on. Instead: keep the adoption report in the plan, with a named owner, until the 90-day mark.

For a worked case of a per-seat tool that grows with the team, see CRM SaaS.

Sources

In three sentences

A SaaS implementation has six phases, requirements, configuration, data migration, integrations, training and adoption, and each one ends with a written output. In the example, a 4% rejection rate on 48,000 records means 64 hours of fixing, and 42 inactive seats at $30 cost $15,120 a year. Test a data sample early, give each task one accountable owner and keep measuring use after go-live, because the rollout is finished only when people work in the new tool.