How We Incrementally Migrated to Next.js and Vercel
Recently, we switched our marketing site over to Next.js and Vercel. In this post, we’ll talk through both why we decided to switch and how we used Next.js Rewrites and API Routes to make the transition seamless.
Why switch at all?
Our previous marketing website used a no-code WYSIWYG editor. We bought a template, customized it a bit, and then moved on.
This experience wasn’t bad, and was helpful in launching a website as a brand new company, but we soon felt like it was holding us back more as we grew. When we wanted to tweak existing designs or add deeper user interaction, it was always harder than we expected.
CSS changes that we’d make to one page were difficult to scope, and so seemingly innocuous changes could break things on other pages. We also didn’t have any way to see the full scope of what we were about to publish or any way to do code reviews pre-publish.
It was important for us to find a solution that would give us the ability to customize our website to fit our needs as a growing brand.
Why Next.js and Vercel?
Our dashboard is written in React, we host authentication UIs for our customers with a server side rendered Next.js application, and we even publish our own React libraries. Going with a React-based framework was a no-brainer given how much time we already spend working with it.
After considering a few different options, we ultimately went with Next.js because of the amount of features it provides out of the box. From small ones, like a built-in router so /pages/features/saml.tsx automatically renders at https://www.propelauth.com/features/saml, to larger features, like easy to use server side rendering and (my personal favorite feature) API routes, Next.js provides a great developer experience.
We then settled on Vercel for hosting. We initially looked at Vercel because of the obvious thought that the makers of Next.js probably know what they are doing for hosting Next.js applications.
On top of that, Vercel provides everything we were looking for in a hosting service. Their preview deployment feature allowed everyone at our company to easily give feedback on proposed changes. Their built-in support for API routes (or Vercel Serverless Functions) allowed us to make simple functions like saving leads, and deploy all that code together:
Most importantly, Vercel’s deploys are incredibly fast and the entire setup process to connect a repo took a few minutes.
Switching to Next.js Incrementally with Rewrites
We timed the switch along with a planned major product release, as we were going to have to change up the marketing site anyway.
The most obvious approach for switching is to build the entire marketing site in Next.js, deploy it, and switch your DNS entries to point to the new site. However, the downside with this option is that we would have to design and build the whole website before it can go live.
Instead, since we had some overlap between the existing and planned site, we decided to prioritize net-new pages and use Next.js Rewrites to fall back to the existing marketing site (or in some cases our docs) for pages we hadn’t created yet.
When users request a route, if it exists in your Next.js application, it will be handled by the new site. Any missing routes will be proxied back to the old site.
https://www.propelauth.com => Found /pages/index.tsx
https://www.propelauth.com/features/saml => Found /pages/features/saml.tsx
https://www.propelauth.com/about => Not found, returning https://old.propelauth.com/about
This worked really well as we were able to ship faster and get feedback sooner. Even after migrating, we still use rewrites to proxy requests to our blog.
Don’t Forget the Sitemap
One thing we were careful of with this incremental strategy was that we didn’t want mess up our sitemap.xml. For instance, if we used a default configuration for next-sitemap, it wouldn’t include all the pages from our old site. Since it was clear that we weren’t building anything new on our old marketing site anymore, we opted to just manually specify them all within that library.
Does a developer need to be involved in every marketing change?
One aspect that held us back from making this decision sooner is that we wanted to make sure that we wouldn’t have to rely on writing code in order to modify the marketing site. In order to make sure that marketing needs wouldn’t be limited by or drain engineering resources in the future, it was important that both technical and non-technical people would be able to contribute.
To achieve this, we used SSR to load the website copy out of Sanity (a CMS). Sanity allows us to create new pages by publishing a new item in a collection and selecting pre-designed template blocks—all without code.
There are still some cases where more complex pages and some interactive elements will need to be manually created by developers, but those requests would been true regardless of whichever framework and CMS we picked.
Summary
Our frontend developers are able to create designs in a format they are already comfortable with (CSS and React). Our marketing team is happy that they can make changes without needing an engineer in the loop.
Overall, we’ve been very happy with our transition to Next.js and Vercel!