A 30-Day Plan for Rolling Out a Document Platform

Deployment is not adoption

“We deployed it” means the platform runs. It does not mean anyone’s Tuesday changed. Two systems can stay live indefinitely — the new one holding the migrated archive, the old one still holding the work.

The difference predicts what you measure. A deployment is done when the checks pass. Adoption is done when a document created on Monday is shared inside the platform on Tuesday without anyone deciding to.

Watch for these in week two.

• Flat active users. Accounts are provisioned, the first team is trained, and the number of people who opened anything this week has not moved.
• Files created and never reopened. A burst of test documents on day one, then nothing. Proof that people can use the platform, not that they are using it.
• The weekly deck still arriving as an attachment. The document was migrated; the habit of emailing it around was not.
• One person editing everything. Usually the champion. It means the workspace has one user and a waiting room.
• Access requests for the old tool. The clearest signal there is. People ask for what they intend to use.

None of this means the platform is wrong. It means the default is unchanged: saving in the old place is still the path of least resistance. Fix the default, not the product.

A deployment ends when the checklist passes. Adoption ends when saving somewhere else stops being the path of least resistance.

Sometimes the honest answer is that the tool is wrong for the team in front of you. If a team’s core process is an inbox of scanned inbound forms that get printed and signed, a document platform is not the fix and no rollout discipline will make it one. Find that out in week two rather than month six.

Start with one team, not a department

A knowledge management rollout aimed at a whole department feels efficient and fails predictably. Four mechanisms:

• The support ratio breaks. In the first fortnight, questions arrive faster than one person can answer them. One champion per 20 to 30 people is workable, and only with hours.
• You lose the ability to fix patterns. Forty people generate forty variants of the same mistake, and no time to correct any of them.
• The feedback is not worth acting on. People who moved because they were told to have no opinion you can use. People who moved because their weekly report got easier do.
• One bad week becomes the company verdict. Roll out to a department on Monday, hit a permission problem on Tuesday, and the platform is “the thing that broke the reporting deck” for a year.

Pick the team with the most document pain, not the friendliest team.

• They exchange documents with people outside the company. External sharing is where a platform proves itself, because the alternative is attachments.
• They have recurring formats. A weekly report, a client proposal, a project tracker. Something that exists in ten versions and wants to be one document.
• They have a deadline inside the quarter. Deadlines produce real documents, and real documents produce real evidence.
• A manager will enforce the switch. Not a manager who approves of it. One who will say no to the attachment.
• They are roughly 15 to 40 people. Small enough to sit with, large enough that the pattern means something.

The team with the most pain is usually a better first team than the team that volunteered. Enthusiasm without documents produces a tidy workspace nobody uses. If no team fits, pick the closest one and describe the month accurately: a usability test, not an adoption test.

Move the daily documents, not the archive

The archive is the easiest content to migrate and the least consequential. It is also where the effort goes, because the counters are satisfying: tens of thousands of files, all verified. A document nobody has opened in a year is not a habit. It is a record, and records can move later in one batch.

The set that decides the rollout is what people touched this week. The weekly report. The tracker the team meets around. The proposal in flight. The meeting note template.

Migration changes where the archive lives. It does not change where work is created, and only the second one is adoption. Give the first team a date, not just a destination: from Monday, new documents start in the workspace, and the copied file in the old tool stops being the one people comment on.

Name an owner, and give the champions hours

• One owner for the rollout. A person with a name, not a steering group. This owner keeps the decision log, grants exceptions, and owns the date the old tool stops. A committee can review; it cannot decide at the speed week two requires.
• Workspace owners per team. Each workspace has an owner who decides the folder shape, who gets access, and what gets pruned. Keep those decisions at group level rather than per file — access control practices for documents explains why per-file permissions become unreviewable at scale.
• Champions with budgeted hours. Two to four hours a week for the first month, agreed with their manager. A champion answers “where does this go”, sits with people while they do real work, and reports the three things that keep breaking. An unpaid volunteer with no hours will be the only active user in the workspace within three weeks.
• The platform admin is a different job. The admin runs the tenant, the accounts and the deployment. The champion runs habits. Collapsing the two roles means nobody is watching either.

Every workspace should also have someone who can say which version is current; without that, the platform fills with the ambiguity the old system had.

Train on real work, and stop counting logins

Feature training does not survive contact with a Tuesday. Run these instead.

• A 45-minute kickoff where each person opens a document they are actually working on. They create it, share it internally, share it with one external address, and find last week’s version. Four tasks, by hand, once.
• Office hours twice a week at a fixed time for the first month. Same day, same hour. Predictable beats available.
• A one-page “where do I find” page inside the platform, updated as the questions repeat.
• Three recordings of under three minutes each — create and share, review and comment, find and restore an old version. Recordings answer the question at 22:00.

Then measure the work rather than the attendance.

Documents created inside the platform each week is the only early metric that means much; logins measure your security review. Documents edited by more than one person tell you whether collaboration is happening, because a single-author document is a file share. Documents sent to external collaborators tell you the platform has become real work instead of a side room. Search failures are the most useful of all: ask the first team every Friday what they could not find, and treat the answers as your folder-structure backlog.

Seat counts come from the operations platform, which shows active users against capacity for each team and can enable or disable accounts in bulk when people move on. Use it to confirm the roster, not as evidence of adoption — an enabled account and a person working are different facts.

Set the date the old tool stops

The most common stall is not a broken platform. It is a working platform that nobody was told what to stop doing. The weekly report still goes out as a re-exported attachment, review comments still land in chat, new drafts still start in the old tool, and the platform copy is politely ignored for six weeks. The platform is fine. The instruction was missing.

So write the stop list down and publish it with the end date.

• The report is the document. Not a PDF exported from it and mailed separately.
• Comments go on the document. Not in a chat thread quoting a paragraph.
• New drafts start in the workspace. Old ones are read-only; nobody needs to move them.
• Ask the champion when it is unclear. One route beats four opinions.

Announce the end date in week one rather than when you feel ready. Put the old tool into read-only before you revoke access, because read-only removes ambiguity first and revocation removes access second.

Exceptions exist, and they should be named rather than tolerated. A valid exception has an expiry and an owner: an external counterparty who will not move, a contract that specifies a format, a regulated record whose retention system is not the platform. “It is easier” is not an exception, it is the default coming back. Review the list monthly; unreviewed exceptions become the second system you were trying to retire.

The first four weeks, concretely:

1. Week 1. Baseline the numbers, kick off with the first team using their own documents, publish the stop list, announce the end date, name the champion and the workspace owner.
2. Week 2. Sit with people. Fix the two biggest friction points — usually search and the folder shape. Watch the five signals above and ask every Friday what could not be found.
3. Week 3. If the signals are right, make the platform the default for the content classes the first team owns, and take the old tool read-only for those classes.
4. Week 4. Measure created and co-edited documents, write down what broke, and choose the second team. The first team’s champion advises the second; the rollout owner does not run both.

If week four is flat, do not add a second team. Fix the first one. A stalled team multiplied by three is a stalled department, and by then nobody will believe the platform was ever going to work.

Sizing for the next wave is the one technical check that belongs in a self-hosted rollout plan: application nodes are estimated from user count rather than from editors, and the deployment documentation covers the formulas and the middleware baselines.