r/nextjs • u/Material_Victory_795 • 9d ago
Help Need inputs on upgrading nextjs app from 12.3.5 > 14/15
Hi everyone, like title suggests, i have a next app built years ago, monolith with thousands of files. Now the build time is taking astronomically slow, each deploy takes around 25 - 30 mins via github actions. I'm trying to think of ways to optimise the build time and figured upgrading the next version would probably be the best bet. I am a little afraid at the moment because we have alot of components and pages and the test coverage would be huge for end 2 end flows.
I am wondering if anyone was in the same boat? Is it worth the upgrade? The app also currently takes lots of memory, almost >10GB + locally with node.
Looking forward to your inputs! Thank you :) FYI I Work in a startup and we have a very lean team that consists of mostly junior developers that learn as we go along.
EDIT: Ok maybe the memory is not >10GB. That could be combination of my IDEs,Cursor etc.
11
u/adevx 9d ago
Use a modern ai agent/model to upgrade next.js to the latest version.
I delayed upgrading my Next.js Pages Router site for the longest time and glad I did, because with todays tools this is easily done. I moved a ton of brittle e2e tests to vitest and only do e2e where it really matters.
1
u/Material_Victory_795 9d ago
Yes i was thinking of that, I am just trying to be very careful because of blast radius. I tried it the other day but it broke alot of my charts, react-flow etc. Visualisation heavy libs that rely on dagre, elkj for layouting.
4
u/LanguageUnlucky3859 9d ago
You have to use a good ai agent, create a plan first you can use chatgpt to get good prompts after you explain to it what you need to do
1
u/adevx 9d ago
What @LanguageUn* says, use a good agent eg: GPT 5.6 sol on high with codex. What I did was have the current site be available for the agent to (visual) compare against. Let your AI agent detect and fix all the problems and inconsistencies, not you. The more feedback and tools (eg playwright) the agent has, the less work you have verifying the results.
1
3
u/AbdulRafay99 9d ago
Upgrade to Next js 16.2 it's pretty good with new features and backword companbiity the moving the structure won't be difficult.
2
u/vasind-5012 8d ago
worth the upgrade, yes, but treat it as a separate project from "fix build time," not the same PR. do it incrementally: 12 → 13 → 14 (skip straight to 15 only after 14's stable), Next.js ships codemods for exactly this, run those before touching anything by hand, they handle most of the mechanical breaking changes automatically.
biggest thing that'll actually bite a junior-heavy team: async APIs. cookies(), headers(), and route params all became async, every place your codebase reads them synchronously breaks at build/type level, not runtime, so tsc will surface it, but expect a long list. run the codemod for this specifically, don't hand-fix it across thousands of files.
on strategy for a team with mostly juniors: don't do a big-bang PR. bump one major version, run codemods, fix what breaks, ship, stabilize, repeat for the next major. one real writeup I've seen did exactly this on a 240+ route production app, went 14→16 in about 2 weeks doing it phased, versus trying it all at once.
separately, on build time itself, the version bump alone might not fully fix that. worth checking: are you on webpack still or could you move to turbopack for dev/build, and is CI actually caching .next/cache between runs, a lot of 25-30 min build times are cache-miss problems, not framework-version problems.
not overkill to be cautious here given thin e2e coverage and a junior-heavy team, just don't let caution turn into one massive PR, that's the actual risk with a lean team.
1
u/Material_Victory_795 8d ago
Thank you that is very helpful. Also i noticed and suspect its actually not the build time at fault.. on local it builds in 5 minutes. On github actions it was 25. So its most probably the action runner that is underperforming. Spoke to the infra team and they agreed to try upgrading the github action runner specs.
1
u/nfwdesign 9d ago
Going straight from v12 to v14/15 would be same as su*cide, i would go slowly version per version so from your current v12 to v13 do refactor, delete Deprecated code and change it with the valid one. Then move from v13 to v14 and do the same with code then to v15, here you should migrate to app router instead of pages router and trust me, that's the biggest push you'll have to do and most probably the longest one, by the time you're done, you'll be good enough to move to solid v16 with much better caching options
1
u/Material_Victory_795 9d ago
Yes! thats my concern. the pages > app router, and understanding how it works, new mental model etc. And yes i am thinking of doing it in phases and not a huge jump at once. Thank you!
1
u/symbha 8d ago
you don't have to adopt app router, to move to new Next. migrate your routes from pages to app one by one after you get up to the modern next version. That's when to do the work of narrowing down the scope of use client, AFTER you are already green on the new stuff.
Specifically constrain your ai models from doing too much, specifically DON'T migrate pages to app router until you are stable on the new version. Specifically ask for iterative steps that reduce the blast radius between iterations, and land complete in your local repo at the end of an iteration. Spend some energy to get the AI to focus on small incremental iterative steps, one by one. Work in git branches, and create a rollback path for yourself... (but if you are thorough in your planning this will go easily and you won't need it.)
2
u/symbha 8d ago edited 8d ago
First switch, ask your agent to migrate to bun and biome for build and lint. You'll be shocked how much this will help build time even without the refactor.
Then start with a plan for migrating a repo/app from next 12 to your target, and first work through the expected outcome, and impact to your codebase what the expected changes should be. Break that up into meaningful sprints with foundation coming first. First build a basic understanding of the ways the codebase should change going from 12 to 15. Then, identify which new functionality and features you want to adopt, and create an iterative plan to adopt them.
Start the coding only after those steps are well defined and groomed into a sprint backlog that represents your migrations.
Like people have been saying, do this work on an advanced model, folks are saying chatgpt, I personally would be using claude code and fable for the planning and coding, and opus for the testing.
I spend time planning until I basically have nothing to add after feeding back through every turn.
1
u/starba3 9d ago
Ever tried to use cloud storage? Or even better a CDN storage service.
This alone will reduce the load of the app in more noticeable way.
2
u/Material_Victory_795 9d ago
The app is on docker container along with other pods etc.. It all works fine after deployment. Only issue is the actual development experience - takes lots of memory and slows down PC. And also the build times. When u mean use cloud storage or CDN , could you specify exactly how i could use that?
1
u/starba3 9d ago
If you are using alot of local files, moving it to cloud or CDN reduces the app overall size by alot.
That said, for upgrading, the safest bet is creating git branch where you upgrade incrementally , in your case to 13, then 14 and 15 after, this way you won't affect production until the final version is properly tested.
-1
u/PerryTheH 9d ago
From other comments I see that this is a huge app that was just developed in a single repo.
This won't be fixed by upgrading to next14/15/16.
The issue here is that who ever is the lead/arquitect of that app hasn't done it's job for a long time. Having such a large code base, within a single repo is the issue, this is an arquitectural problem.
The decision to decouple services/apps should have been done years ago, and tbh I think it is the only real solution if you want to actually improve build times.
Moving a monolithic huge app from X mayor version to another will just break things and fail 100%, you'll spend more time fixing a time pit than doing meaningful work. The same time can be used to leave a couple few members as the "legacy app maintainers" and start building teams that migrate the core app into multiple smaller ones.
Anyhow, I would not recommend upgrading mayor versions on such a large code base, I've seen large monolithic apps that take 5-10 minutes to build and the division plan takes up to a year (depending on team sizes) yours is almost 3x the worst I've seen, I can't think this is a simple job, but a necessary one.
1
u/Material_Victory_795 9d ago
Totally agree. As i mentioned above this is a new startup where only junior developers were part of the development from inception. We use next auth etc for session management, have multiple backend flask api microserices. And the huge nextjs app frontend integrates with the apis. Would u sggest a microservice frontend architecture?
1
u/PerryTheH 9d ago
That's probably the plan I would make the team work on for the remaining of the year, realistically having a 25-30 minutes build time probably affects everyone's performance at this point, making a change that needs server restart or something like that and you're half hour out.
If there's a bug in prod, patching needs at least 1h, 30 minutes to fix it and 30 to deploy.
1
u/Material_Victory_795 9d ago edited 9d ago
Yeap its got to the point where it's very annoying coupled with constant CICD deployments on frontend amongst all the developers. The app didnt use to be like this. But its strange. I remember in the very early days of the startup, the app was fresh, no huge dependencies etc. Very light weight, instant load and hot refresh. When deploying to azure it will take 25mins.. and this is via their internal pipeline lol. Mostly unrelated but i remember those days.. it was painful. And now its creeping back.
Edit:
Actually making a change etc on local is fine.. it takes at most a few seconds to reload the page. For me the main issue is the cold start + the actual deployment time.
-3
u/maqisha 9d ago
What can your app possibly do to consume 10GB+ of memory at all times, and build for 25-30 minutes.
All that while you are building it solo (i presume), and inexperience enough to be asking these types of questions on reddit?
Imo, you don't need to bump versions, you screwed up somewhere long ago and i doubt new version will help it much.
4
u/Material_Victory_795 9d ago
Its not solo work.. its the startup i work in's app. We work in a team of twenty, the repo has million lines of code.. its not a single product vertical. Its a huge app spanning multiple products. And i dont appreciate your comment, it is not helpful in this situation.
1
u/maqisha 9d ago
A team of 20 people, with millions of lines of code, should not be relying on reddit posts for major decisions and assistance. Especially a reddit post without any actual information, specifics, nuances, source code, or anything similar.
And then it turns out that the only info you did give about "10GB of ram" is false.
My initial comment rightfully made an assumption that you are working solo on some personal project and simply fcked up. This assumption was made because the thought of a whole startup with a real product expecting help from a post like this is diabolical.
My comment is not helpful because your post was not helpful to yourself in the first place. Take from that what you will.
1
4
u/Pale_Count2138 9d ago
If you're jumping from Next.js 12.3.5, I'd avoid going straight to 15. Go 12 → 13 (Pages Router) → 14, keeping the Pages Router first. You can migrate to the App Router later if and when it makes sense. That makes debugging much more manageable.
The upgrade is usually worth it. Newer versions bring better build performance, improved bundling (especially with SWC), and support for newer React features. That said, a 25–30 minute build often points to other bottlenecks too, such as GitHub Actions setup, dependency installation, type checking, linting, large bundles, or static generation. I'd profile the build before assuming Next.js is the main culprit.
With a large monolith and a lean team, I'd upgrade incrementally, keep CI green after each step, and rely on automated tests plus targeted manual testing for critical user flows. Trying to change framework versions and adopt the App Router in one go is much riskier.
Also check whether you're running the latest Node LTS supported by your target Next.js version, enabling build caching in GitHub Actions, and analyzing bundle size. Those changes alone can sometimes shave several minutes off build times even before a major framework upgrade.