The material already exists. In most multi-site operations it exists several times over: a binder in each site office, a shared drive with sixty slide decks, a folder of laminated one-pagers near the machine, and a handbook PDF that gets emailed to every new starter. Somebody built all of it, and most of it is correct.
This guide is about the transition itself, not the argument for short modules. It assumes you have already accepted that a phone beats a binder for people who do not sit at a desk, and that what you actually need is a plan: what to move first, what to leave where it is, and how to run the change without leaving a period where nobody knows which version is real.
The content is usually fine, the delivery is not
Worth establishing before you start, because it changes who has to be in the room.
The binder fails on four things and none of them is accuracy. Format: it lives in an office and the work happens on a floor. Cadence: distributing a change means printing, sending and hoping it gets filed. Granularity: it is one artefact where the shift offers gaps of a few minutes. Visibility: there is no way to know who read what.
That means this is not a content rewrite. If you treat it as one, you have signed up for a project that needs every procedure owner's review time before anything ships, and it will stall in month two. Treat it as a change of delivery, with review limited to the moment each item is converted, and the same procedure owners are needed for an hour each instead of a quarter.
Do not convert everything at once
The single biggest cause of failure here is scope. An operator with a binder, fifty decks and a handbook decides to have a complete library by the end of the quarter, freezes all content updates while the migration runs, and discovers in week six that the operation kept changing anyway.
Two things go wrong at once. The people doing the converting are also the people who maintain the material, so the freeze either breaks or the migration stops. And the sites, who were told a new system is coming, spend those weeks with a binder everyone has been told is obsolete, which is the worst possible state for a document to be in.
Convert in waves, keep the old format authoritative until each wave lands, and never freeze the source material.
The inventory that tells you what to convert first
Start with a list, not with an upload. For every active piece of training material, record four things: what it is, which roles it is aimed at, when it was last changed, and how often it gets assigned or re-presented.
That last pair of columns is the whole point. Most inventories rank by importance, which produces a list of everything, because nobody will nominate their own material as unimportant. Ranking by change frequency produces a much shorter and much more useful list.
Expect the inventory to surface two things you did not ask for: material that is assigned to nobody and has been maintained for years out of habit, and material that two departments maintain separately in slightly different versions. Both are cheaper to resolve now than after conversion.
Ranking by update frequency, not by importance
Anything you rewrite more than once a year is a first-wave candidate. It is where the authoring time goes, it is where version confusion between sites already exists, and it is where the benefit shows up within one cycle rather than at the end of the project.
Anything that changes when the law or a client rulebook changes belongs in the first wave too, even if it is currently static. Codex art. I.2-21 requires training to be repeated and adapted as risks evolve, and VCA question 4.1 explicitly names changes to rules and procedures as toolbox content. Material tied to those triggers is material you will have to move again, and moving it once is enough.
Static content with a genuine annual cycle, such as most policy material, can wait for a later wave. It still benefits from conversion, mostly because completion becomes visible, but it is not where the first weeks should go.
Converting in waves: first wave, second wave, the long tail
First wave: the high-churn operational material. Six to ten items, not thirty. Procedures that change, the induction path for your largest role, and anything currently rebuilt every quarter. Run it at two or three sites before the network sees it, and pick sites that will tell you the truth rather than sites that will be polite.
Second wave: the role paths. Once individual items exist, assemble them into sequences per role, with the order following the work rather than the filing structure. This is the wave that changes what a new starter experiences, and it is much easier once the components are already built and reviewed.
The long tail: everything else, on demand. Do not schedule it. Convert an item the next time it needs updating anyway, because that is the moment its owner is already reading it. A long tail converted opportunistically over a year costs almost nothing; the same tail converted on a deadline costs a quarter of somebody's job.
Retiring the old format without a gap
For each item, the switch has three parts and they happen in one day, not over a month.
Publish the module and assign it to the roles that had the old version. Move the source file to an archive folder with the date it was replaced in the folder name, so that anyone who finds it later can see it is superseded rather than current. Remove the old copy from the place people actually reach for it: the induction folder, the shared drive link in the welcome email, the plastic sleeve on the wall.
That third step is the one that gets skipped, and skipping it is what produces a site running last year's procedure with complete confidence, because the version on the wall never announced that it had been replaced.
The moment the binder stops being the source of truth
There is a specific point in this transition where the answer to "what is the current procedure" has to change from the document to the platform, and it is worth naming the date out loud.
Before that date, the module is derived from the document and the document wins any conflict. After it, the source material is maintained in one place, the modules are regenerated from it, and the printed copy in the site office is a convenience copy with no authority. Sites need to be told which side of that line they are on, per item, because the alternative is that each site decides for itself and you get both answers in the same network.
Once you are past that line, the update cycle changes shape. A procedure change is edited at the source, regenerated, and assigned, and the question stops being how long distribution takes.
Working through a stack of decks in Aristotl
Bring the inventory, not the folder. Upload the first-wave items with their roles and their update frequency already known. Slide decks, Word documents and PDFs go in as they are: slide titles become module headings, bullets become sections, embedded images stay where they were. No reformatting, no copy-pasting into a template.
Generate, then review. Each item becomes an interactive module with knowledge checks and scenario questions instead of passive next-slide navigation, built on Socratic questioning, problem-based learning and spaced retrieval rather than on slide order. The review step is the procedure owner reading the output once and approving it.
Assign to the same audience the old version had. Roles and locations carry over, translated per worker, delivered in the browser on a phone with no app to install. Modules run three to five minutes so they fit an actual gap in a shift rather than requiring one to be created.
Archive with a date and keep the version trail. The original file is archived with its replacement date, and every regeneration from the source produces a new version, so that later, when someone asks which sites are on which version, the answer exists rather than has to be assembled.
Pick the deck you rebuilt most recently
The item you last spent an evening updating is the item to bring to a demo. We convert it, assign it to two roles, and show you what the next update to it costs, which is the number the whole transition is really about.