Buying a work platform is the easy part. The hard part is the months after, when a decision made in a meeting has to become the place hundreds or thousands of people actually do their work. Rollouts rarely fail because the software is wrong. They fail because the old tools never went away, because access was set up by hand and drifted, or because people were moved onto a new tool without a reason to stay.
This guide is a staged plan for the rollout itself. It assumes you have already chosen a platform; if you are still choosing, start with how to evaluate an all-in-one work platform. We use Atlas for the concrete examples because it is the platform we can describe from the inside, and we say where it stops.
Why do company-wide rollouts stall?
Two systems of record. When the old tool stays writable, people keep updating it out of habit, and soon nobody trusts either one. A rollout that never retires anything only adds a tool.
Access set up by hand. If the second and third teams are invited one by one, the platform grows its own list of users and permissions that slowly disagrees with your directory. Fixing it later means auditing every account.
Tool-shaped migrations. Moving "everything from the old tracker" drags along years of stale projects and leaves the workflows around them unchanged. Moving one workflow end to end is smaller and shows the benefit.
No visible win. People adopt a new tool when it saves them a step they used to hate. If the first team cannot point to one, the next team will not want to move.
What has to be in place before the second team joins?
Identity and access. The first team can sign up and invite each other. Before anyone else joins, connect the platform to your identity provider so that sign-in, joiners, and leavers follow your directory. In Atlas this is SAML single sign-on and SCIM 2.0 provisioning, including groups, on paid plans; a workspace owner creates the SCIM token in the single sign-on settings. Then map directory groups to roles, and define custom roles where the built-in ones do not fit. From this point, adding a team is a directory change, not an admin chore.
Also decide early who owns the workspace: who can change roles, who reviews the audit log, and who approves agent actions that need a person. Writing these down before scale is far easier than untangling them after.
What are the stages of a rollout?
| Stage | Who is involved | Done when |
|---|---|---|
| 1. Pilot | One team and one sponsor | A full cycle of real work ran on the platform, and the team can name what improved |
| 2. Foundation | IT and security | SSO, SCIM, group-to-role mapping, and audit log review are in place |
| 3. First workflow | The teams on both sides of one handoff | The handoff happens on the platform, and the old path is read-only |
| 4. Expansion | One department at a time | Each new team arrives through the directory with the right role |
| 5. Retirement | Tool owners and finance | Old tools are exported, cancelled, and removed from onboarding docs |
How do you run each stage?
- Choose a pilot team with a painful handoff. A team that loses work between tools today will feel the difference fastest. Atlas is free to start with no credit card, so the pilot does not wait on procurement.
- Set a success test before you start. One sentence, such as "nobody asks for status in the weekly meeting." Measure that, not logins.
- Build the foundation while the pilot runs. Connect SSO and SCIM, map groups to roles, and agree who reviews the audit log. Security should read a week of real entries before more teams join.
- Move the first workflow end to end. For example, signed deal to staffed project: the deal in the CRM, the contract in Contracts, the kickoff project and tasks in Projects. Make the old path read-only on the same day.
- Expand by department through the directory. Add the group in your identity provider and let provisioning do the rest. Give each department one champion who knows the workflows they are moving.
- Turn on the assistant with limits. Start agents with narrow scopes, approval on anything that leaves the company, and a spending cap. Our guide to AI agent governance covers the setup.
- Retire tools on a schedule. Export, cancel, and update onboarding documents so new hires never learn the old path.
How do you move data without breaking work?
Move what is active, archive what is not. Open projects, live deals, and current documents come across. Closed work from years ago can stay in an export you keep. Atlas imports from CSV and Markdown, and we have step-by-step guides for moving from Notion, ClickUp, Asana, and HubSpot, each with a plain list of what carries over and what does not. Run the old tool read-only for one full cycle, then export and cancel.
How do you get people to actually use it?
Remove the reason to go back. If the status meeting still happens, people will keep updating the slide. If the old tracker is still writable, someone will write to it. Replace each old habit with one place: dashboards in Analytics instead of the status slide, Forms instead of request emails, one Search instead of asking a colleague where something lives. Then let the first team tell the next one what changed. A peer saying "I stopped chasing updates" does more than any training session.
What an Atlas rollout can and cannot include today
An Atlas rollout can include SAML SSO, SCIM with groups, custom roles, group-to-role mapping, a hash-chained audit log, data loss prevention on higher tiers, agent governance, a REST API, webhooks, and an MCP server, on one platform of 16 modules. The Enterprise plan adds custom terms for a company-wide rollout.
It cannot include OIDC single sign-on, a SOC 2 or ISO 27001 report, an uptime SLA, a choice of data region, a single-tenant or on-prem deployment, or a BAA. Only three connectors (Gmail, Google Calendar, and Google Drive) can be connected today, three are in beta, and 21 are in development, so plan any other integration around the API. If these gaps block your rollout, start where they do not apply, or wait until they close.
Who this plan is not for
A team of a few people does not need stages; sign up, move the work, and cancel the old tools in a week. A company that has to roll out a regulated system on a fixed date, with certification requirements set in advance, needs a formal implementation program that this guide does not replace. And if the platform you chose cannot meet a hard requirement, no rollout plan will fix that.
What is the first step in rolling out a work platform across an enterprise?
Run a pilot with one team on real work for a full cycle, with a success test written down beforehand. It proves the platform fits before IT and procurement invest in a company-wide rollout.
When should we connect SSO and SCIM?
Before the second team joins. Connecting your identity provider early means every later team arrives through the directory with the right role, instead of being invited and configured by hand.
Should we migrate everything from the old tools?
No. Move active work, such as open projects, live deals, and current documents, and keep older work in an export. Moving workflows rather than whole tools keeps the migration small and the benefit visible.
How long should old tools stay available?
Keep each old tool read-only for one full cycle of the workflow you moved, then export its data and cancel it. A tool that stays writable becomes a second system of record.
Can we roll out Atlas without a sales contract?
You can start free with one team and move to paid plans inside the product. For a company-wide rollout with custom terms, the Enterprise plan is arranged through contact sales.
When should we turn on AI agents during a rollout?
After identity, roles, and audit log review are in place. Start agents with narrow scopes, approvals on external actions, and a spending cap, and read their first entries in the audit log.
Where this lives in wrxstack: security at wrxstack and the Trust Center.