Blank Page After Moving Encoded PHP to a New Server: A Checklist

You migrated a site to a new server, and instead of your application you get a blank white page. Nothing in the browser, maybe a 500 status, and no obvious clue. When the application is built from encoded PHP, a server move introduces several new variables at once, and any one of them can produce that empty screen.

This checklist walks through the likely causes in a sensible order. It is written for the person who owns or legitimately administers the software. Before troubleshooting encoded files, make sure you are authorized to run and maintain them; if the software belongs to someone else, coordinate with them or the vendor first.

First, Make the Error Visible

A white screen is almost always a fatal error that PHP is configured not to display. Your very first move is to see the real message.

Check the PHP error log for the site. On most servers this is configured in php.ini or your control panel, and the last few lines usually name the exact failure. If you cannot find the log, temporarily enable error display in a test environment. Once you can read the actual error, the rest of this checklist becomes much faster, because the message will usually point directly at the cause.

Remember to turn error display back off before the site is public again.

Checklist Item 1: Is a Loader Installed on the New Server?

The most common reason encoded PHP fails after a move is that the new server simply does not have the loader installed. The loader is a PHP extension, and a fresh server or a different host will not have it unless someone set it up.

Generate a phpinfo() page on the new server and look for the encoder's loader section. If it is absent, PHP has no mechanism to run your encoded files, and a blank page or a clear "loader required" message is the expected result. Installing the correct loader for the new server is the fix. Our ionCube Loader explained guide describes what this component is and does.

Checklist Item 2: Does the PHP Version Match?

Even if a loader is present, the new server may run a different PHP version than your old one. Loaders are version-specific, and encoded applications target particular PHP versions.

Compare the PHP version on the old and new servers. A mismatch can mean the loader does not attach, or that the application was never built for the new server's PHP version. If the versions differ significantly, align them or obtain a build and loader appropriate for the new environment. Our note on encoded PHP and PHP upgrades explains this version boundary.

Checklist Item 3: Thread Safety and Architecture

Loaders are built not only for a PHP version but also for a specific build type. A non-thread-safe loader will not work with a thread-safe PHP build, and a 64-bit loader will not work with a 32-bit PHP, and so on.

In phpinfo(), check the Thread Safety and architecture lines on the new server, and make sure the loader you install matches them. Hosts differ in how they compile PHP, so a loader that worked perfectly on the old host may be the wrong build for the new one even at the same PHP version.

Checklist Item 4: Correct php.ini and a Restart

On the new server, confirm which php.ini is actually loaded using the Loaded Configuration File line in phpinfo(). It is easy to edit a file that PHP is not reading. Make sure the loader directive lives in the active configuration and that its path points to a file that exists on the new server.

After any change, restart PHP-FPM or the web server. Configuration changes are not picked up until the process restarts, and a forgotten restart is a classic reason a "fixed" server still shows a blank page.

Checklist Item 5: File Transfer Integrity

Encoded files are binary-sensitive. If they were transferred in ASCII mode over FTP, or altered by a text editor, or truncated mid-transfer, they can be corrupted in ways that produce silent failures.

Re-upload the encoded files using a binary-safe method and compare file sizes against the source to confirm they match exactly. Never open and re-save an encoded file in a text editor, as that can damage it. If a checksum from the original is available, verify it.

Checklist Item 6: Permissions and Paths

A server move often changes file ownership, permissions, and absolute paths. If PHP cannot read the encoded files, or the application expects a path that no longer exists, you can get a blank page.

Confirm the web server user can read the application files, that directory permissions are sane, and that any hard-coded paths in configuration files reflect the new server's layout. Database connection settings frequently need updating after a move as well.

When It Is Actually a Licensing Message

If, once errors are visible, you see a message about an expired license, an invalid site key, or a domain that is not permitted, that is not a technical failure to work around. Licensing is controlled by the vendor. The correct action is to contact them to update or reissue your license for the new server or domain. Never attempt to circumvent these checks.

A Longer-Term Option for Owners

If server moves keep turning into loader-and-version puzzles, and you are the authorized owner of the software, consider recovering plain PHP source from your encoded files. Ordinary PHP source has no loader dependency and no build-type matching to worry about, so migrations become far simpler. Our ionCube decoder and PHP decompiler support this owner-authorized use.

FAQ

Why does the old server work but the new one shows a blank page? The new server most likely lacks a matching loader, runs a different PHP version, or uses a different PHP build type. Any of these can stop encoded files from executing.

How do I see what the actual error is? Check the PHP error log for the site, or temporarily enable error display in a non-public environment. The message almost always names the cause.

Could the files have been corrupted during transfer? Yes. Encoded files must be moved in binary mode and never edited in a text editor. Re-upload them and compare sizes to the originals.

The error mentions my license or domain, not a loader. What now? That is a licensing matter tied to your new server or domain. Contact the vendor to update your license. Do not try to bypass it.

Is source recovery a supported way to avoid this? For authorized owners, yes. Plain source removes the loader and build-matching problems that make migrations fragile. See the FAQ or create an account to begin.