How We Rebuilt Brainguru.in: Two WordPress Sites Into One Next.js Application

This site used to be two WordPress installations. The main site at www.brainguru.in ran a custom theme; the blog ran separately at blog.brainguru.in on a different theme and a different plugin set. They shared a brand and very little else.

We consolidated both into a single Next.js 16 application with a custom content management system, and moved the blog to a path on the main domain. This is an account of how that was done, what the risks were, and what we would do differently. Everything described here is inspectable - it is the site you are reading.

Why We Did It

Three constraints drove the decision, none of them "WordPress is bad". WordPress runs an enormous share of the web perfectly well.

First, two installs meant two of everything - two update cycles, two security surfaces, two sets of design decisions that had quietly diverged. Content overlapped and neither site benefited from the other's authority. Second, the plugin accumulation typical of a long-lived WordPress site had become a maintenance burden where each addition brought its own update and vulnerability profile. Third, performance improvements kept running into the stack rather than into our own code.

The deciding factor was that the blog sitting on a subdomain meant its authority did not consolidate with the main site. Moving it to a path was the single highest-value change available, and doing that well was easier as part of a rebuild than as a WordPress migration.

The Architecture

The application is Next.js 16 using the App Router, rendered statically where possible, with content in MariaDB accessed through an ORM. There is no headless WordPress behind it - the database is the source of truth and the CMS writes directly to it.

Content is organised in three groups. Authored pages cover the service and corporate pages. The original programmatic catalogue contained 600 industry-by-city combinations. Following the 2 October 2026 usefulness review, 598 city URLs redirect to relevant industry pages; two retained city guides contain reviewed local information and cited sources. Blog posts carry their sanitised HTML from the WordPress import, with URLs preserved in the original year and month structure.

Routing resolves all of this through a small number of dynamic segments rather than a file per page. Redirects run in the proxy layer from a map generated out of the database, so adding one is a content operation rather than a code change.

The SEO Work Was the Real Project

Moving a front end is not difficult. Moving it without losing search visibility is where the actual work sits, and it is almost entirely inventory and diligence rather than cleverness.

• Every old URL was mapped to its new equivalent, with permanent redirects.
• The blog subdomain was redirected at the host level to the corresponding path on the main domain at cut-over, preserving the rest of the URL so individual post links continued to work.
• Per-page metadata was captured verbatim from the existing setup rather than regenerated. Titles and descriptions that were already earning clicks are not something to improvise during a migration.
• Structured data was rebuilt from a single source rather than emitted by several plugins with conflicting output.
• The sitemap is generated from the live database on request, so it cannot drift out of step with what actually exists.

The lesson worth passing on: the difficulty is not the redirect mechanism, it is being certain the inventory is complete. Anything missed becomes a 404 that gets quietly dropped from the index weeks later, by which point the cause is hard to trace.

We Had to Build a CMS

This is the part people underestimate. Leaving WordPress means leaving its editorial experience, and if the people who publish content are not developers, that has to be replaced before anyone can work.

We built an admin covering posts and pages with a visual and raw-HTML editor, media uploads, categories and tags, menus, redirects, comment moderation and a leads inbox. Saving content triggers revalidation so changes appear without a rebuild.

Honestly assessed, this was a large share of the total effort. Anyone costing a similar migration should budget for it explicitly rather than treating the front end as the project.

Removing External Runtime Dependencies

A side effect of controlling the stack is being able to remove most third-party requests. Fonts are self-hosted rather than fetched from a font CDN. The icon set is subsetted to only the glyphs actually used and served from our own domain. Client-side libraries are bundled rather than pulled from a CDN at runtime.

The benefits compound: fewer connections to set up, less dependency on someone else's uptime, fewer third-party requests to justify in a privacy assessment, and a content security policy that can be genuinely restrictive because there is little to allow.

What We Would Do Differently

• Build the URL inventory first, before writing any application code. We built the site and then reconciled URLs. Reversing that order would have surfaced edge cases earlier and cheaper.
• Treat media as its own workstream. Years of accumulated uploads across two installs, including every automatically generated thumbnail size, is a larger and messier dataset than expected.
• Decide the CMS scope before starting it. Ours grew feature by feature as editorial needs surfaced. A scoped specification up front would have produced a cleaner result.
• Write the deployment procedure down on day one. Ours was learned through an outage caused by copying build output before the build had finished writing it. That is now a documented rule.

Should You Do This?

Probably not, if you run a small brochure site that changes twice a year and works. The migration cost is real and the benefit is proportional to how constrained you currently are.

It becomes worth considering when you are running multiple installs that should be one, when plugin maintenance and security patching consume real time, when performance is commercially important and the stack is fighting you, or when you need control over markup and behaviour that a theme cannot give. The test is not whether a rebuild would be nicer - it is whether the current platform costs you money or time today in ways you can name.

Handling the Media Library

Two WordPress installs running for years produce a large and untidy uploads directory. Ours held roughly fifteen thousand files across both sites, the majority of them automatically generated thumbnail variants rather than originals.

The instinct is to delete the variants, since the new stack generates its own responsive sizes on demand. That instinct is wrong, and checking saved us from an avoidable outage: a large share of live requests were for those exact variant filenames, because the imported post HTML links them directly. Deleting them would have broken images across hundreds of posts.

The lesson generalises beyond media. During a migration, before removing anything that looks like legacy clutter, check the access logs for whether something is still requesting it. Assumptions about what is unused are frequently wrong, and logs settle the question in minutes.

The Deployment Mistake Worth Learning From

Our worst self-inflicted incident during this project came from copying build output before the build had finished writing it. A build identifier file appears earlier than the finished server bundle, and keying the deployment off that file meant occasionally copying an incomplete build into place - which produced a period of downtime.

The fix is trivial once known: wait for the actual server entry point to exist, not for an intermediate marker. We have since adopted a lower-risk pattern for deployments on this site: the new build compiles in a separate staging directory while the running process keeps serving the current build untouched, and the previous build is held back until the new one passes a health check, so a failed deploy rolls back automatically.

Both are the kind of thing that is obvious afterwards and expensive to learn live. If you are planning a similar migration, write the deployment procedure down and rehearse it before it matters.

What Consolidating the Blog Actually Changed

Moving the blog from a subdomain to a path was the change with the clearest rationale. Search engines treat a subdomain as substantially separate, so authority earned by years of blog content was not helping the service pages that generate enquiries.

Doing it safely required the host-level redirect to preserve the full path so every existing link continued to resolve, redirect entries keyed to account for the path prefix the redirect introduces, and internal links across the site updated to point at the new structure.

Frequently Asked Questions

Why move off WordPress at all?

Not because WordPress is bad - it runs a large share of the web perfectly well. In our case the constraints were two separate installs with duplicated content and diverging designs, an accumulation of plugins each carrying its own update and security burden, and performance that was difficult to improve without fighting the stack. Consolidating into one owned codebase removed all three.

What is the biggest risk in a WordPress to Next.js migration?

Losing search visibility. Every URL that changes must redirect permanently to its new equivalent, and every page that was ranking must survive with its metadata intact. The engineering is straightforward; the risk is in the completeness of the URL inventory. Anything you miss becomes a 404 that Google eventually drops.

Do you lose the WordPress admin experience by moving to Next.js?

You lose it unless you replace it, which is a real cost people underestimate. We built a custom CMS covering posts, pages, media, redirects, menus, comments and the leads inbox. That was a substantial part of the project - moving the front end is comparatively easy, replacing the editorial workflow is not.

Was the migration worth it?

For our situation, yes - one codebase instead of two installs, no plugin update burden, and full control over performance and markup. It would not be worth it for a small brochure site that changes twice a year. The honest test is whether you are constrained by the platform today in ways that cost you real money or real time.

Where Brainguru Can Help

We do this work for other businesses as well as our own. See web development for builds, website redesigning for replacements and replatforms, and software development services for the wider engineering. If preserving search visibility through a move is the concern, that is SEO services, and cloud services covers the hosting side. To talk through a migration, get in touch or call +91-8010010000.