The problem: legacy PHP is a slow-motion outage
A legacy PHP application is usually carrying three risks at once: it runs on a PHP version that no longer receives security fixes, it talks to the database through extensions that modern PHP has removed, and it lives on a single aging server that nobody dares reboot. Every month that passes makes it more exposed and harder to move, because the institutional memory of how it works fades while the attack surface grows. The instinct to leave it alone is understandable and exactly what makes it dangerous — the longer it sits, the bigger the eventual forced migration becomes. This scenario exists to make the move deliberate and reversible instead of an emergency.
How cdn.com.tr solves it: modern runtime, managed data, edge shield
The PHP Platform gives the app a supported PHP 8 runtime with a proper file manager and version selection, so you are no longer pinned to whatever was installed on the old box. The managed database takes the data off that fragile server and puts it on a maintained MySQL service with credentials injected into the runtime rather than pasted into config files. In front of both, the edge layer terminates TLS with Auto SSL and filters traffic with the WAF, so even code that predates modern security practices is not directly exposed to the internet. You modernize the runtime and the data layer while wrapping the whole thing in protection the original app never had.
PHP 8 compatibility: the work that actually gates the move
The migration stands or falls on code compatibility, so this is where the real effort goes. Legacy apps commonly use the removed mysql_* functions, rely on functions deleted or changed in PHP 7 and 8, assume loose type juggling that PHP 8 tightened, or depend on extensions that are no longer bundled. Running the app on a staging copy of the new runtime surfaces these issues as concrete errors instead of surprises in production. You fix them methodically — swap mysql_* for mysqli or PDO, replace removed functions, address the warnings — and re-test until the critical paths are clean. Only then does going live become a routine step rather than a leap of faith.
Database migration without corrupting your data
Moving the data is where silent damage happens if you rush it. The most common trap is character encoding: many legacy databases are latin1 or a mix, and importing them into a utf8mb4 target without care turns Turkish characters and other non-ASCII text into mojibake that is painful to reverse later. The safe path is to import into managed MySQL, explicitly match the source character set and collation, and verify a sample of real records — especially anything with accented or non-Latin text — before trusting the result. You validate the full read/write cycle on staging so that by cutover the database is a known-good copy, not a hopeful one.
Staging and rollback: never gamble with live traffic
The discipline that makes a legacy migration safe is that production keeps running untouched until the new environment has proven itself. You build and test everything on staging, and you keep the old host alive and serving until after the cutover. Lowering the DNS TTL ahead of time means the switch to the edge — and the switch back, if needed — takes minutes rather than hours. If something breaks under real traffic that staging did not reveal, you revert DNS to the old host, fix the issue on staging, and try again. Because nothing about the old environment was destroyed during the move, rollback is a real option and not a bluff.
Optional: standardize future deploys with GitHub
Once the app is on the platform, you can connect its repository through GitHub Deploy so that future changes go out through a repeatable pipeline — Composer install, build, and migration steps defined once and run the same way every time. This turns the one-off migration into an ongoing, controlled deployment flow, which is often the moment a long-neglected app finally gets a maintainable release process. It is optional, but it is where a rescue migration becomes real modernization rather than just a change of address.
How to set it up, step by step
Inventory the app and pick a target runtime
Catalog the PHP version, extensions, cron jobs, and file paths the app depends on, then create a PHP Platform app targeting a supported PHP 8 runtime. Note anything that uses removed functions or old MySQL extensions so you know what code changes are coming before you touch production.
Stand up a staging copy
Deploy the code to the platform as a staging environment and import a copy of the database, so you can exercise the app on the new runtime without any live traffic. Push code either through GitHub Deploy or the file manager, and keep this environment until the migration is proven.
Migrate the database to managed MySQL
Create a managed database, import your dump, and confirm the character set and collation match the original (legacy apps are frequently latin1 or a mixed encoding). Point the app at the managed DB using the platform-provided credentials rather than hardcoding them, and verify reads and writes on staging.
Fix compatibility and re-test on staging
Work through the PHP 8 issues surfaced in staging — deprecated functions, mysql_* to mysqli/PDO, stricter type handling — until the app runs clean. Test the critical paths (login, forms, admin, payments) end to end on the staging URL before anyone talks about going live.
Attach the domain, Auto SSL, and WAF
Bring the domain onto the CDN account, let Auto SSL prepare the certificate, and enable the WAF so old code is shielded the moment it faces the public internet. Keep the origin reachable only through the edge so the app server is never exposed directly.
Cut over DNS with a rollback ready
Switch DNS to the edge during a quiet window with a low TTL set in advance, so if a problem appears you can revert quickly. Keep the old host running and untouched until the new environment has proven itself under real traffic, then decommission it.
Example scenarios
A long-running forum on end-of-life PHP is moved to PHP 8 and managed MySQL, with read-heavy archive sections cached at the edge and the WAF blunting bot abuse.
A bespoke PHP CMS is lifted onto the modern runtime as-is after compatibility fixes, buying years of safe operation without a full rewrite.
A line-of-business PHP tool running on a single aging box is migrated to managed runtime and database, removing the single point of failure that kept everyone nervous.
Frequently asked questions
My app uses the old mysql_* functions. Will it run on PHP 8?
Not as-is — those functions were removed years ago. The migration includes replacing them with mysqli or PDO, which is exactly the kind of issue that staging surfaces as clear errors so you can fix it before going live rather than discovering it in production.
How do I avoid garbling Turkish characters during the DB move?
Match the source character set and collation explicitly when importing into managed MySQL, and verify sample records containing accented or non-Latin text on staging. Encoding mismatches are the most common silent failure in legacy migrations, so you validate it before cutover, not after.
Can I test everything before touching the live site?
Yes, that is the core of the approach. You run a full staging copy on the new runtime with a copy of the database, prove the critical paths, and only then move DNS. Production keeps running on the old host the whole time.
What if something breaks right after cutover?
You revert DNS back to the old host, which is still running and untouched, then fix the issue on staging and retry. Setting a low DNS TTL ahead of the cutover keeps that rollback down to minutes.
Do I have to upgrade all my code at once?
You need enough compatibility work that the app runs cleanly on the target PHP 8 runtime, but you don't have to rewrite the application. Many legacy apps move with a focused set of fixes; a larger refactor can happen later once the app is safely on the platform.
Is my old code safe once it's exposed to the internet again?
The edge WAF and Auto SSL sit in front of the app, filtering common attack traffic and enforcing HTTPS before requests reach the origin. Combined with keeping the app server reachable only through the edge, this gives legacy code protection it never had on its old host.