In a post to his site Fabian Schmengler has shown how to use class_alias to prevent breakage while renaming or moving classes around in your application during refactoring.

Sometimes you want to rename a class or move it to a different namespace. But as soon as it is used anywhere outside the package, this is breaking backwards compatibility and should not be done lightheartedly.

Luckily there is a way in PHP to have both, the old class and the new class, while deprecating the old one: class_alias().

He then gets into the details of using this handy function to define the links between the files, necessary in two different places to prevent autoloading breakage. He also offers an alternative, making use of the "autoload.files" option in the Composer configuration (but this means adding each one to that list). He finishes the post by suggesting one more thing as you update your code: making it with an @deprecated annotation to help locate it later (and flag it in your IDE of choice).

Paul Jones has posted an article to his site with another helpful hint to modernize your legacy PHP application. In the post he looks at updating serialized object handling with the help of the class_alias function.

Several weeks ago, a correspondent presented a legacy situation that I’ve never had to deal with. He was working his way through Modernizing Legacy Applications in PHP, and realized the codebase was storing serialized PHP objects in a database. He couldn’t refactor the class names without seriously breaking the application. [...] Before I was able to reply, my correspondent ended up changing the serialization strategy to use JSON, which was a rather large change. It ended up well, but it turns out there is a less intrusive solution: class_alias().

He talks about how this function could be useful to prevent the need for updating the class name in every serialized instance by setting up an alias to the new name. You can even use namespacing in the alias that will let the autoloader work with the PSR-0/PSR-4 handling to correctly load the class. With this in place, you can then refactor to the new version of the class without worry of breakage.