Taking over a Next.js website another agency built: what to check first.

Agencies close and developers move on, and a business is left with a website nobody can change. On Next.js that's recoverable. These are the seven things we check first when we take one on.

Agencies close, developers move on and a business is left with a website nobody on the team knows how to change. If the site is built on Next.js, that's recoverable. The code is ordinary and widely known: 20.8% of developers in Stack Overflow's 2025 survey said they use Next.js.

These are the seven things we check first when we take one on, in order.

1. Get the keys.

Before anyone touches the code, make sure the business holds every account the site depends on. Ask the old agency for each one, and move it into your own name.

The hosting account matters more than it looks. The site's secret settings, such as API keys, usually live there and nowhere else.

2. Find out which version it's on.

The version is in a file called package.json in the code. Next.js 16 is the current major version, released in October 2025.

Sites built before May 2023 usually use the older Pages Router. The newer App Router became stable in Next.js 13.4. The Next.js docs say the Pages Router is still supported, so an older site doesn't need rewriting just for that. But the further behind it is, the bigger the upgrade.

3. Check for known security flaws.

Next.js has had two critical flaws in the last two years. In March 2025, CVE-2025-29927 let an attacker skip login checks made in middleware, rated 9.1 out of 10. It affected self-hosted sites on versions 11.1.4 to 15.2.2. Sites hosted on Vercel or Netlify were not affected.

In December 2025, CVE-2025-55182 let an attacker run code on the server without logging in, rated 10 out of 10. It hit Next.js 15 and 16 sites using the App Router. Next.js advised that any site still unpatched on December 4, 2025 should change its secret keys as well as update. More fixes for related flaws followed in January 2026.

Next.js also publishes a support policy. Version 16 gets full support. Version 15 gets only critical and security fixes. Version 14 and older get none, so a site on them won't be fixed when the next flaw is found.

So check the exact version against the advisories and run npm audit, which lists known flaws in everything the site installs. Update before anything else.

4. Make sure it builds.

Copy the code, install it and run a production build on a clean machine. Missing settings are the usual reason it fails. If you hold the hosting account, you can find them there. Then put the build on a private preview link and click through every page type.

5. Look at the content system.

Find out where the content lives and whether your team can still log in. Export a full backup before you change anything. If the site has no content system and every edit goes through code, note that now. It's the biggest factor in whether to upgrade or rebuild.

6. Check what visitors see.

• Test speed on a phone in PageSpeed Insights.
• Send every form and confirm the message arrives where it should.
• Look in Google Search Console for errors and pages that dropped out.
• Crawl the site for broken links.

7. Add the checks it never had.

Most inherited sites have no automated checks. Before the first real change, add a production build and tests that run on every change, preview links for each change and backups of the database. Then plan the upgrade in small steps, each one checked on its own.

Keep, upgrade or rebuild?

• Keep it if it's current, builds cleanly and your team can edit it. Add the checks and move on.
• Upgrade it if it's a version or two behind but well built. That's usually cheaper than a rebuild.
• Rebuild it if every edit needs a developer, it's several versions behind and the design no longer fits the firm. How a rebuild works covers that path.

How we take one on.

We read the code first and tell you what we'd keep and what we'd change before we quote. Once we've taken it on, we host and look after it like a site we built, with hosting and support from $150 a month. If you ever leave, we hand the code back in a repository you own.

See how we build on Next.js and Payload, or book a call and tell us what you've inherited.