What Old Website Files Can Be Removed?
A cautious method for identifying obsolete CMS, server and build files after a successful migration.
Do not delete before archive
First preserve a complete pre-migration copy. Cleanup is safer when recovery does not depend on memory.
Remove obsolete application code from public hosting
If the replacement is static, old CMS core files, plugin folders, database admin scripts and unused PHP/ASP.NET code should generally not remain executable in the public document root.
Watch server configuration leftovers
Old .htaccess, web.config and .user.ini files can keep affecting a new static site even when no page links to them. Review them deliberately instead of assuming they are harmless hidden files.
Keep only active assets
Unused JavaScript libraries, old themes, duplicate CSS bundles and obsolete image variants add confusion and sometimes risk. Preserve them in the archive, not necessarily in production.
Re-scan after deletion
Crawl the live site and review server logs. A file that seemed unused may have been serving a form endpoint, verification file or external integration.
Hidden files deserve special attention
Legacy deployments frequently leave configuration files that normal file managers hide. Examples include .htaccess, .user.ini, environment files and verification files. Some are critical; others keep old rewrite or PHP settings alive. Review hidden files explicitly before declaring the migration clean.
Do not remove verification files blindly
Search engines, certificate authorities and external services may depend on small HTML or text verification files in the document root. Confirm ownership and purpose before deleting them as “unused.” A cleanup that removes a still-active verification token can create problems unrelated to the visible website.