← Writing index

Field note / Freelance · Next.js · Web Development

Reviving a Legacy Portfolio Website with Next.js and Vercel

How I rebuilt Richard Mabbitt’s missing WordPress portfolio from archived pages and moved it to a simpler, modern deployment.

At first, the job sounded simple: bring Richard Mabbitt’s portfolio website back online.

Then I learned that the WordPress database was missing, the original provider controlled the domain, and most of the site’s content no longer existed in a form I could restore.

What looked like a migration became a small digital reconstruction project.

More than a website migration

Richard is an independent consultant in urban and regional planning and environmental management. His portfolio presents his experience, services, projects, biodata, and gallery.

The website had been built and maintained by a third-party company. The arrangement worked, but the recurring cost had become difficult to justify for a site that rarely changed.

Richard also wanted more control over his online presence. Hosting, maintenance, and the domain were all tied to the existing provider. He reached out to me through a mutual friend to see whether I could move the site to something simpler.

My first task was to understand what still existed.

What survived from the WordPress site

I gathered the available files and reviewed the original setup. The site had been built with WordPress, which would normally make migration fairly routine if both parts of the site were available:

  • The WordPress files, including its theme, plugins, and uploaded media
  • The database containing pages, posts, menus, metadata, and settings

I had the source files, but not the database.

That missing database changed the project. The theme could show me how the old site had been styled, but most of the content and structure could not be restored conventionally.

I had the shell of the website, but not the information that made it useful.

I could continue searching for a backup that might not exist, or rebuild the portfolio from the material I could recover. Because the site was mostly static, rebuilding offered the better long-term result.

Choosing Next.js over another WordPress setup

The client did not need a full content management system. He needed a fast portfolio that was inexpensive to operate and straightforward to maintain.

I chose Next.js because it gave me:

  • Reusable components for the shared page structure
  • Static generation for pages that rarely change
  • Clear control over metadata and navigation
  • A maintainable codebase without a live WordPress installation
  • A direct deployment workflow through Vercel

Next.js is more framework than every static website needs, but it suited this project. The rebuilt site could remain mostly static while still having a clean structure for future changes.

The decision was not about replacing WordPress because it was old. It was about removing complexity the client no longer needed.

Reconstructing the site from web archives

The hardest part was recovering the content.

Fortunately, the Wayback Machine had captured versions of the original public website. Those snapshots were not a backup of the WordPress application, but they provided enough evidence to reconstruct the portfolio:

  • Page copy and portfolio details
  • Navigation and page relationships
  • Visual hierarchy
  • Images and other assets that had been captured
  • Older versions of pages that were no longer live

I reviewed the archived pages one by one, recovered the useful material, and rebuilt each section in Next.js.

Archive snapshots are imperfect. Some assets may be missing, interactive behavior may not replay, and captures from different dates can be inconsistent. I treated them as a blueprint rather than source code.

The goal was not to clone a broken website. It was to recover its identity and rebuild it on a foundation the client could own.

That distinction gave me room to preserve what mattered while simplifying the implementation.

Deploying the rebuilt portfolio

Once the pages were ready, I deployed the application to Vercel. Its Next.js integration made the build and deployment process predictable, without requiring me to maintain a separate web server.

The domain required more coordination.

Because it had previously been managed by the maintenance company, the relevant DNS records had to be updated to point to the new deployment. After the records were changed and the configuration was verified, the portfolio became available again through its original domain.

Seeing the site load from that address was the moment the reconstruction felt complete.

What changed for the client

The rebuilt portfolio gave Richard:

  • Control over the new hosting and deployment
  • Lower ongoing maintenance overhead
  • Faster static pages
  • A codebase that is easier to update
  • Fewer moving parts than the previous WordPress setup
  • A clearer path for future changes

Most importantly, richardmabbitt.com was online again without depending on the old maintenance arrangement.

My first direct client project

This was my first direct client engagement after stepping away from a traditional full-time industry role to focus on my master’s degree.

The technical work mattered, but it was only one part of the project. I also had to understand what Richard wanted, explain the available options, set expectations around missing data, and provide regular progress updates.

Balancing the project with postgraduate study made planning equally important. I broke the work into clear stages:

  1. Investigate the existing site and available assets
  2. Decide whether recovery or reconstruction was realistic
  3. Rebuild and review the portfolio
  4. Deploy the site
  5. Coordinate the domain transition

That structure helped keep the project manageable and gave the client a clear picture of what was happening.

What the project taught me

The project reinforced a few lessons I want to carry into future client work.

Choose technology for the actual requirement. The client needed a stable portfolio, not a feature-rich CMS. A static-first Next.js application solved that problem with less operational work.

Missing information changes the solution. Once the database was unavailable, treating the job as a normal migration would have wasted time. The Wayback Machine created another path forward.

Communication is part of engineering. Technical decisions only help when the client understands their consequences and feels informed throughout the process.

Ownership matters. Hosting and domain access are part of the product, not administrative details to think about after launch.

Bringing a digital presence back to life

This project began as a request to restore a portfolio and became a complete reconstruction. I recovered what I could from public archives, rebuilt the site with Next.js, deployed it through Vercel, and helped return the domain to a working website.

The finished portfolio is live at richardmabbitt.com.

The result was valuable to the client, but it also marked an important step for me. I managed the investigation, technical direction, implementation, deployment, and delivery myself.

Sometimes the right way to preserve an old website is not to restore every part of its original system. It is to understand what mattered, carry that forward, and give it a simpler place to live.