Mahindra Insurance Brokers Limited (MIBL)
Enterprise Drupal Modernization for BFSI Leaders
- Drupal
- PHP 8
- Enterprise Cloud
Off an unsupported version
Drupal Migration and Modernisation
Drupal 7 reached end of life and stopped receiving security fixes. Sites still on it are running unpatched, and most of them are the sites an organisation depends on most. This is the work of getting off, in stages, with the site live throughout.
What Drupal Migration and Modernisation covers
Drupal 7 reached end of life and no longer receives security fixes. Sites still running on it are unpatched, and in our experience they are usually the sites an organisation depends on most, which is precisely why nobody has wanted to touch them.
A Drupal migration is not a redesign, and treating it as one is what turns a contained project into an open ended one. The work is moving content, structure, users and URLs onto a supported version with the site still behaving as people expect. A redesign can follow once you are safe, as a separate decision with its own budget.
The part that decides whether it succeeded is the least visible: every existing URL mapped to its replacement and redirected. Search rankings survive a migration when that map is complete, and they are lost when it is an afterthought. We treat it as a deliverable, not as a launch day task.
Is this the right fit?
A fit when
- You are on Drupal 7 or an unsupported version and security is now the issue
- A migration was attempted before and stalled
- The site has thousands of pages and manual migration is not realistic
- Search rankings on the current site are worth protecting
- A long content freeze is not something the organisation can absorb
The wrong choice when
- The site is small and old enough that rebuilding is genuinely cheaper, which we will tell you if it is true
- Nobody can answer questions about what the content means
- You want a redesign at the same time, which is possible but should be priced as two things
- The current site is already on a supported version and working, where migration is cost without benefit
What you get
Audit and migration plan
What is on the current site, what is worth bringing, what has not been visited in three years. Usually a third of the content does not need to move.
Automated content migration
Migration written as repeatable code, not manual copying. It can be re-run as often as needed, which is what lets the old site stay live until the last day.
URL and SEO preservation
Every old URL mapped to its new destination, redirects tested before launch. This is where most migrations quietly lose their traffic.
Module and custom code review
What has a Drupal 10 equivalent, what has to be rewritten, and what was only ever needed by a feature nobody uses now.
Parallel running
The new platform built alongside the old one, with content re-synced until cutover. No freeze while the build happens.
Cutover and rollback
A planned switch at a quiet hour, with a tested way back if something is wrong. Nobody should be improvising on launch night.
How it runs
-
Assessment
A written report on the current site: content volume, custom code, modules without a forward path, and what the migration will actually involve. You get this before committing to the build.
-
Migration build
The migration written as code and run repeatedly into the new platform, so problems surface early rather than on cutover weekend.
-
Verification
Content checked against the source, redirects tested, and the new site crawled to catch what the migration missed.
-
Cutover
The switch, at a low-traffic hour, watched. Search Console and analytics monitored for the following weeks so a ranking drop is caught in days.
Built with
The platform and the tools around it. Nothing here is chosen because it is new.
- Drupal 10
- Drupal 7
- Migrate API
- PHP 8
- MySQL
- Solr
- Docker
- GitHub Actions
Delivered like this
Enterprise Academic Platform for NSUT
Engineering a Scalable Drupal Platform for a Premier Technical University
- Drupal
- PHP
- MySQL
Questions we get asked
Will we lose search rankings?
Not if the redirects are done properly, and that is the part we spend most care on. Every old URL is mapped and tested before cutover, and we watch Search Console afterwards rather than assuming it went fine.
How long will the site be frozen?
It should not be. The migration is written as repeatable code, so the old site keeps running and publishing until the day of cutover.
Do we have to bring all the content?
No, and you probably should not. A content audit usually finds a large share of pages that nobody has visited in years. Moving them costs money and dilutes the new site.
What if we started a migration and it stalled?
Common, and worth talking about. The first step is the same assessment: what was done, what is usable, and what it would take to finish rather than restart.
Can we redesign at the same time?
You can, but we price it as two pieces of work. Combining them makes it impossible to tell whether a traffic change came from the migration or the redesign.
Tell us what you are building.
Send the problem and any constraints you already know about. You get a scope, an approach, and a real cost range - written by a person.