I ran kudutek.com on WordPress for six years. It worked fine—until it didn't.

Plugins breaking with every update. Hosting costs climbing. Page load times getting worse. The classic WordPress trajectory.

I wanted to move to Next.js. Static generation, full control, modern development experience. But rebuilding an entire site solo? That's a months-long project.

Then I started using Claude Code. Three weeks later, the new site was live.

Here's how it actually happened—including the parts that didn't go according to plan.


The Starting Point

What I had:

  • 85 blog posts in WordPress
  • Custom theme with specific styling
  • ConvertKit newsletter integration
  • Contact forms
  • XLNavigator product pages
  • Years of accumulated technical debt

What I wanted:

  • Next.js 14 with App Router
  • MDX for blog posts
  • Fast page loads (100/100 Lighthouse)
  • Full control over everything
  • No plugins, no PHP

What I feared:

  • Losing SEO from URL changes
  • Broken links everywhere
  • Design inconsistencies
  • Months of tedious migration work

Week 1: Foundation and Architecture

Day 1: Project Setup

I started by asking Claude to set up the project structure:

Set up a Next.js 14 project with:
- App Router
- TypeScript
- Dark/light theme toggle
- CSS custom properties for theming
- Basic layout with header and footer

Twenty minutes later, I had a working skeleton. Claude knew all the Next.js 14 patterns—no fumbling through documentation.

Days 2-3: Design System

The tricky part: WordPress had a specific look. I needed to recreate it without copying code.

I took screenshots of key pages and asked Claude: "Build a design system that matches this aesthetic."

It generated CSS custom properties, component styles, and theme variables. Not pixel-perfect, but close enough to iterate from.

What worked: Describing the aesthetic in words ("Editorial luxe, serif headings, clean spacing") rather than trying to extract WordPress CSS.

What didn't: Some spacing was off. I had to manually adjust padding and margins to match my eye. Claude doesn't do visual QA.

Days 4-7: Core Pages

I built the essential pages one at a time:

  • Home page
  • About
  • Contact
  • Blog listing
  • Individual blog post template

For each page, I'd show Claude the WordPress version and say: "Build this in Next.js with our design system."

It generated components, routing, and basic functionality. I'd review, adjust styling, and move on.

Key lesson: I didn't try to get it perfect the first time. Claude built v1, I identified issues, Claude fixed them. Iteration was faster than perfection.


Week 2: Content Migration

This is where most migrations die: manually copying 85 blog posts.

The Content Problem

WordPress stores content in a MySQL database with HTML formatting, shortcodes, and plugin-specific markup. I needed clean MDX files with frontmatter.

I exported the WordPress database and asked Claude: "Write a script to convert these WordPress posts to MDX files."

It generated a Node.js script that:

  • Parsed the WordPress XML export
  • Converted HTML to Markdown
  • Extracted featured images
  • Generated proper frontmatter
  • Created clean filenames

What worked: The script got 80% of posts perfect. The other 20% had edge cases (embedded videos, custom shortcodes, tables).

What didn't: Some posts had WordPress-specific HTML that didn't convert cleanly. I had to manually fix ~15 posts.

The URL Redirect Problem

I changed my URL structure: /excel/excel-date-picker/ became /blog/excel/excel-date-picker/.

Broken links destroy SEO. I needed 301 redirects for every old URL.

Claude generated a redirect configuration for next.config.mjs:

async redirects() {
  return [
    {
      source: '/excel/:slug',
      destination: '/blog/excel/:slug',
      permanent: true,
    },
    // ... 50+ more redirect patterns
  ]
}

It analyzed my old site structure and created wildcard patterns to catch everything.

Critical insight: I verified every redirect manually using a script Claude wrote to crawl the old site and test each redirect. Found 3 edge cases that needed explicit redirects.


Week 3: Polish and Launch

The Styling Refinement

The design was 90% there but needed polish. I went room-by-room (page-by-page):

"The hero section feels too cramped on mobile." "The blog cards need more breathing room." "The footer signup form needs better contrast."

Claude adjusted the CSS each time. Some changes I kept, some I tweaked further.

What I learned: Claude is great at bulk styling changes but not at subjective design judgment. I had to be the art director.

The Performance Optimization

Next.js is fast by default, but I wanted 100/100 Lighthouse scores.

I asked Claude: "Analyze this page and suggest performance improvements."

It recommended:

  • Image optimization with next/image
  • Font subsetting
  • Lazy loading for below-the-fold content
  • Removing unused CSS

I implemented each suggestion. Went from 85/100 to 98/100. The last 2 points were minor issues I decided to ignore.

The Final Polish

  • Mobile responsiveness checks
  • Dark/light mode consistency
  • Form validation
  • Error handling
  • 404 page
  • Sitemap generation
  • RSS feed

Each of these was a conversation with Claude: "Build X feature" → review → refine → done.


What Claude Did Well

1. Boilerplate and Setup Setting up routing, TypeScript configs, component structure—Claude handled this instantly. No more copying from old projects.

2. Pattern Application Once I established a pattern (e.g., blog post frontmatter format), Claude applied it consistently across all posts.

3. Tedious Refactoring "Make all these components use the new design tokens" → done in seconds. No manual find-and-replace across 50 files.

4. Documentation Reading Claude knows Next.js 14 App Router patterns. I didn't read the docs once. I just asked questions.


What Claude Struggled With

1. Visual Design Judgment Claude can't look at a page and say "this feels off." I had to be specific: "increase padding by 20px" not "make this look better."

2. Complex State Management For the newsletter signup with modal flow, I had to architect the state logic myself. Claude implemented it, but I designed it.

3. Edge Cases The first pass missed edge cases: What if a blog post has no author? What if the excerpt is empty? I had to think through these and ask Claude to handle them.

4. Third-Party Integrations Setting up ConvertKit API integration required reading their docs and trial-and-error. Claude helped with the code but didn't know their API quirks.


The Results

Timeline:

  • Week 1: Foundation and core pages
  • Week 2: Content migration and redirects
  • Week 3: Polish and launch
  • Total: 3 weeks part-time (~40 hours)

Without Claude: I estimate this would have taken 2-3 months.

Performance:

  • Lighthouse: 98/100 (was 75/100 on WordPress)
  • Page load: 0.8s (was 3.2s)
  • Hosting cost: $0 (was $29/month)

SEO:

  • No traffic drop after migration
  • All old URLs redirect properly
  • Search rankings maintained

What I'd Do Differently

Start with a design system: I built components as I went. Should have defined all design tokens upfront. Would have saved cleanup time later.

Write more tests: I tested manually. Should have asked Claude to write automated tests for critical paths.

Document decisions: I made architectural choices on the fly. Should have kept a CLAUDE.md from day one documenting patterns and preferences.

Plan the migration in phases: I tried to do everything at once. Should have launched MVP and iterated. Perfect is the enemy of shipped.


The Bottom Line

Could I have done this without Claude? Yes, eventually.

Would I have started without Claude? Probably not. The perceived effort was too high.

That's the real value. Claude didn't just save time—it made a project that felt overwhelming feel manageable. That psychological shift is what got me to actually do it.

If you're sitting on a migration project, just start. The first conversation with Claude is: "Help me plan the migration." Take it one piece at a time.

Three weeks later, you might be writing your own migration story.



Official Resources


Considering a similar migration? Happy to share specific details about any part of this process.