Migrate from Pages Router to App Router

[DarshanCode2005]

Summary

The conference website is currently using the legacy Next.js Pages Router (pages/), while running Next.js 16. Since Next.js 13.4, the App Router (app/) has been the recommended routing system, and all new features are being built for it.

This issue tracks the migration from Pages Router to App Router using the official migration approach.

This migration can be done incrementally, so there is no need for a risky “big bang” rewrite.

---

Why migrate now?

Reduce future migration effort

Every new page or feature built on the Pages Router will eventually need to be rewritten. Migrating now prevents additional migration debt.

Improve contributor experience

Most modern Next.js tutorials, documentation, and learning resources use the App Router. Migrating helps new contributors work with familiar patterns and lowers the barrier to contribution.

Access modern Next.js features

The App Router enables features that are not available in Pages Router, including:

• React Server Components (smaller client bundles)
• Built-in SEO metadata via metadata / generateMetadata
• Streaming and improved loading states
• Server Actions and modern data-fetching patterns
• Improved layout system with nested layouts

Align with current Next.js best practices

Pages Router is still supported but is in maintenance mode. App Router is the actively developed and recommended architecture.

---

Current scope

The migration includes:

• Moving routes from pages/ to app/
• Migrating _app.tsx to app/layout.tsx
• Replacing getStaticProps / getStaticPaths with App Router equivalents
• Migrating API routes to app/api/.../route.ts
• Updating SEO metadata handling
• Adding 'use client' to interactive components where needed

This migration can be performed gradually, and both routers can coexist during the transition.

---

Migration plan

Phase 1 : App Router scaffold

• Create app/ directory
• Create root app/layout.tsx
• Move shared layout (Navbar, Footer, BackToTopButton)
• Ensure both routers work together

Phase 2 : Migrate pages incrementally

• Home page
• Venue pages
• Editions page
• CFP / registration page

Phase 3 : Migrate API routes

• Move pages/api/... routes to app/api/.../route.ts

Phase 4 : Cleanup

• Remove pages/ directory
• Remove _app.tsx
• Update tests and configuration if needed

---

Benefits

• Aligns with modern Next.js architecture
• Improves performance and SEO
• Reduces client-side JavaScript where possible
• Makes the project easier for new contributors to understand
• Enables future framework features

---

Additional notes

• Next.js supports incremental migration, so this can be done safely in phases
• Netlify supports App Router, but deployment should be verified after migration
• Interactive components using React hooks will need 'use client'

Resources

• Next.js App Router documentation
  https://nextjs.org/docs/app

• Official migration guide
  https://nextjs.org/docs/pages/guides/migrating/app-router-migration

[DarshanCode2005]

@TenzDelek, @AceTheCreator Sir , I’m not entirely sure if this is the right time to raise this issue, but I believe it would be best to address it sooner rather than later. The longer we continue building new features on the current setup, the more complex and time-consuming the migration will become in the future.

[Sreejesh06]

@DarshanCode2005 Looks like we’re on the same wavelength 😄 i too thought the same . I’m up for working on this together if you are. We can split it based on the phases you mentioned and run in parallel.
If mentors are also aligned that this needs to be done now, then maybe you and I can just partner up and close this out quickly.
Let me know 👍

[TenzDelek]

Good suggestion. This sounds like a good subtask for GSoC #919. What do you think, @AceTheCreator?

[pggdev]

@DarshanCode2005, Good idea. I would like to help you with this issue.

[DarshanCode2005]

Thank you so much @pggdev and @Sreejesh06 for your enthusiasm and willingness to contribute I genuinely appreciate your interest and support. I wanted to share that I have already completed most of the migration outlined in this issue, which is why I was able to provide detailed implementation notes and highlight the remaining work. Currently, I am in the middle of my mid-term exams, so there has been a slight delay in opening the PR, but I will be prioritizing this and plan to submit a well-structured PR soon. To avoid duplicated effort and to respect everyone’s time, I would kindly suggest holding off on parallel migration work for the same areas. That said, I would absolutely welcome your involvement in reviewing the PR, testing it, identifying edge cases, or suggesting improvements. I am very open to collaboration and would be happy to co-author commits for meaningful contributions. That’s the true spirit of open source , collaboration and shared learning. Sir @TenzDelek , since this migration might be considered as a GSoC subtask, I hope this PR can serve as a useful starting point and reference for whoever takes this forward under yours and @AceTheCreator mentorship. I would be happy to assist with context, implementation details, or any support needed to ensure a smooth transition. If anyone would like to collaborate, discuss improvements, or report issues, please feel free to reach out to me here on GitHub, on LinkedIn, or via email at darshan_t@me.iitr.ac.in. I would be glad to connect and work together.