Maganin: an archive moved off three platforms without losing an address

Maganin is an Arabic-language socio-mental-health network: long-form articles, consultancies, doctor profiles and categories, read right to left by people looking for help. Its content had outlived two platforms. The public site ran on classic ASP with addresses search engines had indexed for years, the admin ran on Angular 10 over a generated Java API, and a hosting deployment nobody wanted to keep paying for sat in between. The 2026 rebuild moved the whole network onto Next.js 15 for the public, doctor and admin surfaces, a Java 21 and Quarkus 3 API over MySQL, and one Docker Compose deployment behind Caddy, with every old address still resolving.

What changed, measured

1. Every legacy addressStill resolves after the moveOld routes, including the content and consultancy views, redirected in middleware so years of inbound links keep working instead of 404ing quietly.
2. 3 to 1Platforms consolidatedA classic ASP public site, an Angular 10 admin over a generated Java API, and a separate hosting deployment became one Docker Compose stack the owner can run.
3. 90 daysThe old host stayed up after cutoverSo anything the URL inventory missed had somewhere to land rather than going dark while nobody was watching.
4. 11Numbered steps in the cutover runbookWritten for the owner to read, not for us: build, configure, restore, verify each page type, lower the DNS TTL a day ahead, switch, keep the old host, decommission, schedule the backup.

What it is built to produceBuilt so the owner can publish again on a maintained platform at the cost of a VPS, without readers or search engines losing the addresses they already know. The checkpoint against the archived baseline has not closed, so no traffic or ranking figure is claimed here.

The archive is the business

Maganin, which means the mad ones in Arabic and wears the name with intent, had been publishing since before the site that was carrying it existed. Long-form articles, a directory of consultancies and the doctors behind them, and categories that let a reader in difficulty find the right kind of help.

Everything of value was the writing and the links pointing at it. That single fact decides how a migration like this is scoped: you are not rebuilding a website, you are moving an asset and trying not to drop it.

Three platforms, one liability

The public site was classic ASP, with addresses that had been indexed for years. The admin was an Angular 10 application over a generated Java API, 37 commits between 2021 and 2022, with a separate hosting deployment in the middle that somebody was still paying for.

Nobody could safely change the public site. The admin's framework was two major versions behind. The content, and the links pointing at it, were the asset; everything wrapped around them was the liability, and it was compounding quietly every month nobody touched it.

Keep the data. Replace the surfaces.

The entities that mattered, articles, content, categories, consultancies and consultancy types, moved unchanged into a Java 21 and Quarkus 3 API with versioned schema migrations, so the archive came across intact and reversibly. The public site, the doctor surface and the admin were rebuilt on Next.js 15, right to left from the root element, with the API's anonymous reads serving articles, consultancies, doctors and categories.

Keeping the domain model is what makes a migration boring, and boring is the objective. Every entity you redesign during a migration is an entity you cannot diff against the old system when something looks wrong at two in the morning.

The addresses are the asset

This is the question every owner actually asks before a migration, and it deserves a direct answer: will we lose what we have got.

Not if the redirects, canonicals and metadata are mapped before cutover rather than discovered after it. Every old route, including the content and consultancy views, is redirected in middleware to its new home. The clean-up scripts in the migration folder rewrite the stale links the old platform had left inside the article bodies, which is the part people forget: your own internal links are also inbound links. And the old host stays up for ninety days after cutover, so anything the inventory missed lands somewhere instead of going dark.

Running it without us in the room

One Docker Compose deployment: the API, the database restored from the archived dump, and Caddy issuing TLS automatically so a certificate can never expire because a person forgot. A daily dump cron writes backups outside the containers. Health and metrics live at a management endpoint, wired before the cutover rather than added after the first incident. Secrets are copied from an example file and never committed.

The runbook is eleven numbered steps the owner can read without us: build, configure, bring up, restore, verify each page type, lower the DNS time-to-live a day before, switch, keep the old host, decommission the old deployment, schedule the backup. A migration that only one person can operate has not finished.

What is not claimed

The rebuild is engineering, and it is written up as engineering. No traffic or ranking result is claimed for Maganin; the checkpoint against the archived baseline has not closed.

What can be said is that the archive is on a maintained platform, the addresses work, the backups run, and the owner can publish.

Key Features

• Every legacy address, including the content and consultancy views, redirected in middleware, so years of accumulated inbound links survive the move intact
• The content model kept rather than redesigned: articles, consultancies, doctors, categories and consultancy types migrated with their history, because the archive is the asset
• A Java 21 and Quarkus 3 API with schema migrations, token security, caching and health and metrics endpoints wired before cutover rather than after it
• A Next.js 15 public site laid out right to left from the root element, with anonymous reads so an article is a page a crawler and a reader both get in full
• A database restore from the archived dump plus clean-up scripts that rewrite the stale links the old platform had left inside the article bodies themselves
• One Docker Compose deployment with automatic TLS, a daily database dump written outside the containers, and secrets kept out of the repository
• A written cutover runbook in eleven numbered steps, including the DNS time-to-live lowered a day ahead and the old host kept alive for ninety days

Business Impact

The owner can keep publishing on a platform that is maintained, on hosting that costs what a VPS costs, without losing the addresses readers and search engines already know. Three stacks became one. The admin is no longer two major framework versions behind the thing it administers. The migration is written up here as an engineering story because that is what it was: no traffic or ranking figure is claimed, and the checkpoint against the archived baseline has not closed. If you are weighing a migration, the transferable fact is the order of operations. The URL inventory came before the rebuild, not after it.