Cleaning Up a CMS Without Stopping the Press
A live CMS was cleaned up for a growing editorial team without taking the site offline or pausing publication.
Project Details
Systems Consultant / Implementation Lead
The organization had been publishing continuously for years. The CMS had accumulated the decisions of every person who had ever touched it, including people no longer there whose logic was never written down. Content types that started precise had been stretched. Fields meant for one kind of data were used for another. The media library was full of filenames like "final_v3_USE-THIS-ONE.jpg." The team doing the publishing were writers and editors, not system administrators. As the team grew, unwritten rules were not being absorbed consistently. Publishing errors were becoming more common: wrong images, content in incorrect categories, things requiring manual cleanup.
Make the CMS usable for a growing team without taking the site down, interrupting publishing, or requiring the team to learn anything new.
The site could not go offline. Publishing could not pause. There was no technical staff. Whatever I built had to work for the people who were actually there.
Execution
I asked to sit alongside two or three team members while they published. Not to watch over their shoulder, but to see the actual sequence of decisions from finished article to clicking publish. I was looking for workarounds. Every workaround is a signal about where the system fails the user.
What I found fell into three groups. First: things causing active errors, a handful of content types with required fields being regularly skipped and overlapping category schemes. Second: things messy but functional, like the media library naming. I documented rather than cleaned these. Third: things that bothered people aesthetically but had no operational consequence. I left those alone.
For categorization, I worked with two senior editors to draw hard lines between blurring categories. We removed ambiguous subcategories and mapped them to clear parents. I did this in staging first, validated, then applied to production during low-traffic windows at night over three evenings across two weeks.
The media library was different. You cannot rename thousands of files without risking broken references. I created a naming convention for everything going forward and documented it as part of a one-page publishing guide. One page on purpose. A guide that requires scrolling does not get consulted during a deadline.
I trained one person internally as the point person for questions. I chose the person the team already went to informally. You cannot make someone an authority by giving them a title; you find the person who already has the informal authority and make their knowledge portable.
Outcomes
Publishing errors dropped sharply within the first month. The categorization ambiguity was gone. When there is only one correct place for something, it ends up there.
The guide got used. The questions the point person fielded shifted from "where does this go?" to "the guide says X but in this case Y." The team had internalized the workflow and were working through edge cases, not fundamentals.
When working with a live system and a non-technical team, the most dangerous thing is moving fast. The second most dangerous is imposing something the team did not help build. I know how to slow down and distinguish between what needs to change and what just looks like it does.