At Yoma Fleet, the whole IT team builds and runs the systems behind Yoma Car Share, PLUS+, Yoma InnoSights, and our financial services products. Until recently, the knowledge those teams produced, runbooks, onboarding guides, architecture notes, sprint retrospectives, lived scattered across ClickUp tasks, comments, and ad hoc docs. Finding the right page meant knowing which team wrote it, when, and under which task. A new hire could not read their way into the team; they had to ask someone who already knew.
We set out to fix that with a single, structured IT knowledge base built in Coda (recently Superhuman Doc), with Claude working alongside us as a research and drafting partner throughout. The goal was not just to move files from one tool to another. It was to read every page, decide what was still useful, and rebuild it as something a new team member could act on independently. Today, every wiki we scoped is migrated. None were left out.
Why ClickUp Wasn’t Built to Be a Knowledge Base
Before the migration, ClickUp held our knowledge the way most fast-moving IT organisations end up storing it: inside the work itself. Each of our nine teams, covering software engineering for PLUS+ and Car Share, frontend & mobile, IoT, DevOps, QA, data, PM, and ACE (business analysis, content, and design), had its own ClickUp space for sprints and tasks. Reference material lived inside those same spaces, attached to tasks, buried in comments, or written once and never revisited.
That structure works for tracking a sprint. It does not work as a library. A DevOps runbook written inside a closed task effectively disappears once the task is archived. A new QA engineer cannot browse “how we test” the way they would browse a wiki; they have to ask someone who remembers which task it lives under. Cross-team context, how PLUS+ approvals work, who owns InnoSights telemetry, sat in people’s heads more than on any page. We had documentation. We did not have a knowledge base.
Building the IT Knowledge Base: What We Did
We treated the migration as a content problem first and a tooling problem second.
The first move was a gap analysis, not a copy job. Before anything moved to Coda, we read through what existed in ClickUp and asked one question of every page: Is this still useful, accurate, and used? Migrating bad documentation into a better tool does not fix bad documentation; it just gives it a nicer home. Pages that were stale, duplicated, or no longer matched how a product actually worked got cut rather than carried over.
With that filter applied, we built the skeleton before the rooms. Every team wiki we migrated afterward had to fit into or link back to that skeleton rather than duplicate it. If a fact already lived in the master reference, the team wiki pointed to it instead of repeating it. That single rule kept the knowledge base from becoming eleven slightly different versions of the same answer.
Claude worked alongside us through this as a drafting and structuring partner: reading large batches of scattered ClickUp content, proposing how it should be organised inside Coda, and cross-checking facts against live sources before anything went into a public-facing page. The rule was to confirm a product fact, an app store URL, a live status, against the real source before drafting copy around it, not after. The human sign-off stayed with us; Claude did the heavy reading and the first draft.
The tooling had its own honest friction. ClickUp’s document API surfaces top-level pages by default, no matter how deep you set the depth, so nested sub-pages needed a second, targeted search to find at all. On the Coda side, a page that returned empty content through the standard page-read call almost always still had real data sitting in the table beneath it; reading the table directly was the reliable fix. Neither was a blocker once we knew the pattern, but both would have cost real time if we had not hit them early and written the workaround down.
What Changed
The result is a knowledge base that did not exist before this work started: every wiki we scoped, across all nine IT teams, is migrated into Coda. Nothing was left out.
| What we measured | Before | After |
| Structured team and product wikis in Coda | Context lived solely in ClickUp; hard to find content | Every scoped wiki live: InnoSights, PLUS+, Car Share, Content, DevOps, Data, Design, Dev, PM, QA, and IoT |
| AI assistant training material | None | 130+ training questions built across all nine teams, covering both team-based and role-based scenarios |
| Migration completeness | N/A | 100 percent of scoped docs migrated; no team skipped |
We did not migrate everything that ever existed in ClickUp, only what passed the gap analysis. That is by design: a smaller, accurate knowledge base beats a complete but stale one.
Lessons Learned
Is it perfect? Not yet. A few honest lessons from the process.
Permissions are not a content problem; they are a setup problem, and the two look identical from the outside. When a page failed to update with no clear content error, the cause was almost always a missing share on the document, not a missing instruction. We learned to check access before debugging content.
The deduplication rule was harder to enforce than to write. It is easy to agree that a fact should live in one place; it takes discipline, page by page, to actually point to the master reference instead of rewriting the same paragraph because rewriting felt faster in the moment.
AI accelerated the reading and the first draft. It did not replace the judgment call about what was still true. Every page that went into the AI assistant’s training bank, and every fact in the AEO content, still needed a person to confirm it against the live product before publishing.
Looking Ahead
The migration itself is done, but the cadence is not a one-time project. We review and refresh Operations, Tech, and Reports content regularly, and People and Reference twice a year, so the knowledge base does not drift back into the state we just fixed. The next phase is the site-facing side: applying the same gap-analysis discipline to our technical work for yomafleet.com, so the structured facts we built for internal use also hold up for search and for AI asssitant answer engine reading the knowledge base.
Conclusion: A Knowledge Base Is a Habit, Not a Project
Moving from ClickUp to Coda gave Yoma Fleet’s IT members one place to find an accurate answer instead of a person to ask. Claude gave us the speed to read and structure material at a scale a single writer could not have managed alone. Neither replaces the other: the IT knowledge base we have today exists because the gap analysis was as rigorous as the migration, and because every fact that mattered enough to publish got a human check before it did. That is the standard we are holding the next quarterly refresh to as well.
