Claude Code as a Migration Partner

Over two days in late March, I migrated three websites containing 20 years of content from a dying CentOS 7 server to a modern static archive. The primary operator wasn't me -- it was Claude Code, Anthropic's AI coding assistant, running on my Mac and SSH-ing into servers while I supervised.

This isn't a product endorsement. It's a reflection on what the collaboration actually looked like in practice -- what worked, what didn't, and what it means for how technical work gets done.

The setup

Claude Code runs in a terminal on my Mac. It can execute shell commands, read and write files, and maintain context across a long session. For this project, it was SSH-ing into two servers: the old CentOS box being decommissioned and the new OVH Debian server receiving the archive. I watched, directed, and intervened when needed.

The project involved auditing a server's disk usage, cleaning up hundreds of gigabytes of cruft, spidering 24,000 dynamic web pages, rsyncing 54GB of media, running post-processing scripts across 29,000 HTML files, configuring a web server, setting up databases, optimising Lighthouse scores, and handling DNS cutover. A proper infrastructure migration with real data at risk.

Where it excels

The standout capability is repetitive operations at scale. When you need to strip Google Analytics tags from 29,000 HTML files, or add lazy loading attributes to 387,000 image tags, or rewrite URLs across an entire site -- this is tedious, error-prone work for a human and trivially parallelisable for an AI. Claude Code wrote the sed and Python scripts, tested them on a single page, then applied them across the full dataset. The feedback loop was minutes, not hours.

Debugging was another strength. During post-processing, some image tags were corrupted with byte sequences that shouldn't have been there -- \x01 and \x02 characters embedded in the HTML. Claude Code identified the source (an overly broad regex in the accessibility fix script), diagnosed why it was happening (backreference capture groups interacting with binary-like content), and wrote the corrective script. That kind of systematic diagnosis across thousands of files is exactly where pattern-matching at scale pays off.

The Lighthouse optimisation session was particularly effective. Claude Code could parse the JSON audit output, identify which specific recommendations were actionable, propose fixes, apply them, and verify the results -- all in a tight loop. The entire Performance/Accessibility/Best Practices/SEO optimisation was done in a single session.

Where it still needs a human

Architectural decisions were entirely mine. What content to keep, what to archive, what to let go. Whether to attempt recovering the corrupted vBulletin forum data or mark it as a future project. Whether placeholder images for missing icons should be grey boxes or something more descriptive. These are judgement calls that require understanding the history and the audience, not just the technical constraints.

Visual verification was another gap. Claude Code can check that a URL returns a 200 status code, but it can't tell you that the flexslider carousel looks broken, or that the logo is rendering with corruption artefacts, or that the archive banner's positioning feels wrong on mobile. Every significant change needed a visual check in the browser.

Domain knowledge mattered more than I expected. Understanding the CMS architecture -- how the URL routing worked, why mediafiles were on subdomains, which images were article content versus site chrome -- all of this informed decisions about what to spider, what to rsync, and how to configure the web server. Claude Code could investigate and report, but the interpretation required context that came from having built and maintained these sites for fifteen years.

The collaboration pattern

The working rhythm settled into something natural. I would set a direction: "Spider the three sites, rsyncing media separately." Claude Code would investigate the current state, propose a plan with specific commands and configurations, and wait for approval. Once approved, it would execute, monitor progress, handle errors, and report results. I'd review, spot-check visually, and set the next direction.

It's not pair programming exactly -- more like having a very capable, very fast junior engineer who never gets tired, never loses context, and is extremely good at following a systematic process. The "junior" part matters: it will confidently execute a plan that has a subtle flaw if you don't catch it first.

Mistakes and recovery

The biggest incident was a post-processing script with a greedy regex that was supposed to strip Google Ads divs but ended up eating significant chunks of page content across all 29,000 pages. The pages were mangled badly enough that we had to re-spider the entire dataset and start the post-processing from scratch.

The lesson wasn't that the AI made a mistake -- humans write greedy regexes too. The lesson was about safety nets. We'd taken hardlink snapshots before the post-processing started, which meant recovery was possible without re-downloading everything from the old server. After the incident, we adopted a stricter pattern: test every regex on a single page, visually verify the output, then apply at scale.

The flexslider breaking when jQuery was deferred was a more subtle issue. The fix was technically correct -- deferred scripts load faster -- but it didn't account for a runtime dependency that wasn't visible in the code without understanding the initialisation sequence. That's the kind of thing where human experience with legacy JavaScript catches what static analysis misses.

Speed

What would have taken me two to three weeks of evening work was completed in roughly two full days. The audit alone would have been a day of SSH-ing around and taking notes. The spidering was largely waiting, but the post-processing -- writing scripts, testing, applying, debugging, iterating -- would have been the real time sink. Claude Code compressed the iteration cycle from "write script, test, find bug, fix, retest" spanning hours into tight loops spanning minutes.

Trust but verify

The operating principle throughout was: trust the execution, verify the output. Every post-processing script was tested on one page before being applied to 29,000. Every Caddy configuration change was tested with curl before being declared complete. Every Lighthouse optimisation was verified with a fresh audit.

This isn't unique to working with AI -- it's just good operational discipline. But it matters more when the operator can execute changes faster than you can review them. The speed that makes AI assistants valuable also makes verification non-negotiable.

What it means

I don't think this replaces the need for technical understanding. If anything, it amplifies it. Having deep knowledge of the systems involved meant I could direct the work effectively, catch problems early, and make good architectural decisions. Without that background, I'd have been unable to evaluate whether the proposed approaches were sensible.

What it does replace is the drudgery -- the hours of repetitive file manipulation, the careful but tedious script writing, the systematic testing across thousands of pages. The parts of infrastructure work that are intellectually simple but operationally demanding. Handing those to an AI while retaining the interesting decisions is, genuinely, a better way to work.