Adding Composer to a Legacy PHP Project

Adding Composer is usually the first reversible modernization win: you gain a dependency contract without rewriting business logic. The goal of the first pull request is not a perfect PSR-4 tree—it is a committed composer.json/composer.lock, a generated vendor/ on deploy, and a single autoload require that coexists with the old bootstrap.

Before you run Composer

• Create a version-control branch and a filesystem/database backup of the environment you will change
• Identify the true application root (the directory that should own composer.json, usually above the web document root)
• Note the production PHP version and required extensions with php -v and php -m on the same SAPI you deploy
• List third-party libraries currently copied into the tree—those become early require candidates

/var/www/app/
  public_html/          ← document root (index.php)
  lib/
  config/
  templates/
  third_party/phpmailer/

/var/www/app/
  composer.json
  composer.lock
  vendor/
  public/               ← document root
  src/
  config/
  templates/

Minimal first composer.json

{
  "name": "acme/legacy-app",
  "description": "Internal application",
  "type": "project",
  "require": {
    "php": ">=7.4"
  },
  "config": {
    "platform": {
      "php": "7.4.33"
    },
    "sort-packages": true
  },
  "autoload": {
    "classmap": ["lib/"]
  }
}

Set platform.php to the PHP version you actually run in staging/production so developers on newer laptops do not resolve packages you cannot install on the server. Raise the constraint when the runtime ladder moves—see platform constraints.

Wire the autoloader without deleting includes