/* ══ r78: signal wall + readability + glitch ══ */ /* ── r78: live signal wall ────────────────────────────────────────── Real /api/pulse numbers rendered as instrument readouts on marketing pages. Values are injected client-side; the markup is server-rendered placeholders so layout never jumps. */ #muthurSignalWall{ display:flex;gap:0;flex-wrap:wrap;margin:26px 0 8px; border:1px solid #1d4a2e;background:rgba(4,17,10,.55); } #muthurSignalWall .mwall-cell{ flex:1 1 140px;min-width:140px;padding:12px 16px; border-right:1px solid #122918; } #muthurSignalWall .mwall-cell:last-child{border-right:none} #muthurSignalWall .mwall-num{ font:700 20px/1.2 ui-monospace,SFMono-Regular,Menlo,monospace; color:#4ef58a;letter-spacing:.06em; text-shadow:0 0 10px rgba(78,245,138,.35); font-variant-numeric:tabular-nums; } #muthurSignalWall .mwall-lbl{ font:10px/1.5 ui-monospace,monospace;letter-spacing:.16em; color:#6f9c7d;text-transform:uppercase;margin-top:3px; } @media(max-width:640px){#muthurSignalWall .mwall-cell{min-width:110px;padding:10px}} /* ── r78: readability pass ────────────────────────────────────────── Calmer reading density on chat transcript + marketing prose. Additive, color/typography/spacing only — no layout rewrites, no chrome changes. */ .marketing-copy, .muthur-marketing section p, .card p, .msg-body p, .msg-inner p{ line-height:1.75; } .muthur-marketing section p{margin:0 0 1.15em} .msg-row{padding:14px 0;border-bottom:1px solid rgba(126,184,145,.09)} .msg-row:last-child{border-bottom:none} .msg-body{line-height:1.7} .msg-body ul,.msg-body ol{line-height:1.75;margin:.7em 0;padding-left:1.4em} .msg-body li{margin:.3em 0} .msg-body pre{line-height:1.5} .muthur-marketing{max-width:880px} @media(min-width:1100px){.muthur-marketing{max-width:920px}} /* ── r78: glitch micro-events (homepage boot line) ────────────────── Occasional 1-frame phosphor flicker on the boot glyph line. Pure CSS animation, ~0.4% duty cycle, honors prefers-reduced-motion. */ @keyframes muthur-glitch-flick{ 0%,96.2%,100%{opacity:1;transform:none;text-shadow:inherit} 96.6%{opacity:.55;transform:translateX(.5px)} 97.1%{opacity:1;transform:none} 97.5%{opacity:.7;text-shadow:-1px 0 rgba(255,60,60,.35)} 98%{opacity:1;transform:none;text-shadow:none} } .muthur-boot-line,.empty-logo{ animation:muthur-glitch-flick 13s steps(1,end) infinite; } @media(prefers-reduced-motion:reduce){ .muthur-boot-line,.empty-logo{animation:none} }
M7 MU/TH/UR 6000
SIGNALS IN ARCHIVE
OPERATIONS TODAY
// PUBLIC TRANSMISSION / PLANNING

Six-Week Plan for Migrating from Google Docs to a Self-Hosted Wiki

The conversation outlines a structured six-week plan for a 15-person team to migrate from Google Docs to a self-hosted wiki, detailing phases, strategies, and criteria for success and rollback.

A read-only, creator-approved conversation screened before publication.

USER

Build a six-week plan to migrate a 15-person team from Google Docs to a self-hosted wiki. Include rollout phases, a champion strategy, resistance handling, data migration order, success metrics, and rollback criteria.

MU/TH/UR

SIX-WEEK GOOGLE DOCS -> SELF-HOSTED WIKI MIGRATION PLAN Team: 15 people. Assumes wiki already chosen (BookStack, Wiki.js, or Outline all work for this size; pick one and stick with it) and server/auth is provisioned in Week 1. PREREQUISITES (before Week 1 starts) - Wiki installed, HTTPS, daily backups, SSO or shared accounts provisioned for all 15. - Full inventory of Google Docs: count, owner, type, last-modified date, and who links to each. - Information architecture agreed: 4-6 top-level spaces (e.g. Engineering, Operations, People, Projects, Reference, Archive). WEEK 1 - FOUNDATION & INVENTORY - Configure wiki spaces, permissions, and templates (doc, meeting notes, project page, decision record). - Complete the Google Docs inventory; tag every doc as Active / Reference / Template / Stale. - Publish a 1-page "why we're moving" note (search, single source of truth, ownership, versioning) and a migration FAQ. - Recruit champions (see below) and hold Kickoff. Announce timeline and the safety net: nothing is deleted. - Exit criteria: all 15 have wiki logins; inventory tagged; IA live. WEEK 2 - PILOT (champions + 1 friendly team) - Migrate ~10-15 highest-value docs for the pilot team only. - Champions build the onboarding guide, templates, and a 30-min training session. - Run first training; collect friction notes and fix the worst 3-5 pain points (search, permissions, editor quirks). - Exit criteria: pilot team uses wiki for all new docs for 5 straight working days; training materials finalized. WEEK 3-4 - BULK MIGRATION (in priority order, see below) - Migrate Active docs first, then Reference, then Templates. Stale docs are frozen, not migrated. - Migrate by team, one team at a time (3-4 teams over 2 weeks), so each team gets a champion-led handoff. - All NEW documents are created in the wiki from Week 3 onward (soft cutover for new content). - Google Docs stay editable (read-write) during this phase - it is the safety net. - Exit criteria: all Active and Reference docs migrated and linked from wiki; no team still creating new docs in Google. WEEK 5 - CUTOVER - Google Docs switched to READ-ONLY. Update bookmarks, shared links, and the old docs' headers to point to the wiki. - Publish the "where did it go" index page (old doc name -> wiki link). - Freeze-and-archive remaining Stale docs (move to Archive space or a zip, no migration effort). - Exit criteria: 95%+ of docs migrated or archived; 0 teams dependent on Google Docs for daily work. WEEK 6 - STABILIZE & DECISION GATE - Measure success metrics (below). Run retrospective. - Clean up orphaned wiki pages, fix broken links, tune search. - Hold the rollback decision gate: if rollback criteria are met, execute rollback now (Google Docs still read-only, so it's a 1-day flip back). If not, archive the Google Docs and finalize. CHAMPION STRATEGY - Pick 3-4 champions (one per team, not all managers): early adopters, technically comfortable, respected by peers. - Champions do: migrate their team's docs, run their team's 30-min training, answer day-to-day questions, report friction to you weekly. - Give them: early access in Week 2, a direct escalation line to you, visible recognition (announcement, shout-outs), and one hour/week of protected time. - Meet champions weekly for 30 min during Weeks 2-5 to triage issues and adjust the plan. RESISTANCE HANDLING - Identify resistors in Week 1 (people who push back or stay silent in kickoff). Do one-on-ones, not group debates. - Address root causes, not symptoms: fear of losing work (solve with read-only safety net + backups), tool fatigue (solve by retiring the old tool, not adding a third), unfamiliarity (solve with champions + templates, not docs). - Make the wiki the default, not the mandate: all new docs in wiki from Week 3, but old Google Docs keep working until cutover. - Lead with quick wins: show search beating Google Docs, ownership clarity, no more "which version is this". - Get one senior leader to visibly use the wiki daily - top-down cover beats bottom-up pleading. - Never delete anything without notice; deletion anxiety is the #1 resistance driver. DATA MIGRATION ORDER (by value and churn, not alphabetical) 1. ACTIVE docs (in-progress work, edited weekly) - migrate first while they're still live; highest value, highest risk if lost. 2. REFERENCE docs (onboarding, policies, runbooks, how-tos) - high value, low churn; migrate second. 3. TEMPLATES - migrate third, and convert them into native wiki templates with placeholders. 4. MEETING NOTES & ARCHIVES - bulk-migrate fourth, low effort, low risk. 5. STALE docs (no edits in 6+ months) - DO NOT migrate. Freeze, archive, and link from the index. Only migrate if someone requests it. Rationale: fresh content first (people notice immediately), stale content last (nobody notices, saves effort). SUCCESS METRICS (measure at end of each week, report at Week 6 gate) - Adoption: % of team with wiki activity in the last 7 days. Target: 80%+ by Week 6. - Migration completeness: % of Active+Reference docs migrated. Target: 95%+. - Time-to-find: median time to locate a known document. Target: under 1 minute. - Google Docs usage: weekly open/edit counts trending to ~0 by Week 6. - Version/confusion incidents: count of "which version is this" or duplicate-doc reports. Target: near 0. - Support load: champion/helpdesk questions per week, trending down after Week 4. - Content freshness: % of wiki pages updated in last 30 days. Target: 50%+. ROLLBACK CRITERIA (decision gate at end of Week 5, final gate end of Week 6) Trigger rollback if any of: - Weekly active users under 40% at end of Week 4 with no upward trend. - Any confirmed data loss or corruption in migrated content (backup restore failed). - Wiki downtime exceeding 4 hours total in any week, or unresolved critical bug blocking daily work. - A team formally escalates an unresolvable blocker (e.g. required feature missing) and champions agree. Rollback mechanics (cheap because Google Docs is kept read-only until Week 6): - Flip Google Docs back to read-write (1 day). - Re-point the index page and bookmarks to Google Docs. - No data deleted at any point - wiki is additive, so rollback loses nothing. - Full rollback window is Weeks 1-5. After the Week 6 gate, rollback means restoring from the archive instead of flipping a switch. One rule that makes this work: never delete a Google Doc until the Week 6 gate has passed. The safety net is what lets you push hard on adoption without triggering panic. Want me to turn this into a tracked spreadsheet (owner, date, status per step) or draft the Week 1 kickoff message next?

FORK THIS TRANSMISSION →OPEN YOUR OWN TERMINAL →ASK A FOLLOW-UP →

RELATED SIGNALS