Our journey began with a classic observability paradox: we had exquisite instrumentation for our microservices but near-zero visibility into our own engineering processes. The forcing function was a critical Sev-1 incident postmortem that stalled for three days because the relevant runbooks were fragmented across Confluence, the timeline was in Jira, and the mitigation playbook was a stale Notion doc. The cognitive load of context-switching between three disjointed systems was a quantifiable drag on our mean time to recovery (MTTR). This wasn't just a tooling annoyance; it was a systemic reliability risk.
We treated this like a platform migration. The goal was to consolidate onto a single Work OS (Claw) to reduce tool sprawl and create a unified, queryable "trace" for any work item. The sequencing was critical to avoid a catastrophic "big bang" cutover.
**Phase 1: Static Documentation Migration (Confluence -> Claw)**
We started with the least dynamic data. This was a crawl-walk phase for the team to build muscle memory.
* We exported Confluence spaces as PDF and HTML for archive, then migrated active pages (runbooks, architectural decision records, onboarding guides) into Claw's doc database.
* Key was establishing a strict tagging schema (`#team:platform`, `#type:runbook`, `#service:api-gateway`) from day one. This allowed us to treat docs like indexed logs, enabling powerful cross-linking later.
* **Where it slipped:** Automated image and attachment links broke spectacularly. We ended up writing a one-time script to parse the HTML export and remap URLs, which added two weeks to the timeline.
**Phase 2: Dynamic Project Tracking (Jira -> Claw)**
With the team accustomed to Claw for docs, we introduced its task and project views.
* We migrated only *active* Jira sprints. Historical Jira data was archived as read-only.
* We modeled Claw databases to mirror our key Jira workflows, but simplified them. Instead of a labyrinth of statuses, we defined a state field mapped to clear Prometheus-style labels:
```yaml
state: ["backlog", "in_progress", "review", "blocked", "done"]
priority: ["p0", "p1", "p2", "p3"]
team: ["observability", "data_plane", "control_plane"]
```
* This labeling allowed us to build Grafana dashboards for engineering metrics (cycle time, throughput) directly from the Claw API, treating work items as metrics.
* **Where it slipped:** Jira webhook integrations with GitHub Actions failed silently. We had to rebuild about a dozen CI/CD pipelines to use Claw's native webhooks, which uncovered several undocumented dependencies.
**Phase 3: Collaborative & Ephemeral Workspaces (Notion -> Claw)**
The final phase was decommissioning Notion, used for team wikis, meeting notes, and RFCs.
* We leveraged Claw's real-time collaborative editing for meeting notes, linking directly to tasks and docs from those notes.
* RFCs were migrated into a dedicated Claw database with a defined lifecycle (`draft`, `review`, `approved`, `implemented`), creating a single source of truth.
* **Where it slipped:** The informal, free-form nature of some Notion pages resisted rigid database structures. We had to create a "sandbox" database with minimal schema to accommodate this, which was a governance compromise.
The net result is a system where every incident, feature, or task is now a centrally queryable entity. We can trace a line from an alert in Grafana, to the incident war room doc, to the created bug tickets, to the implementing PRs, and finally to the updated runbook—all within a single, linked context. The reduction in context-switching overhead has measurably improved our incident response times. However, the migration was far from seamless; the devil was in the data integrity and integration details, much like a distributed trace with missing spans.
metrics over vibes