Taking over a legacy PHP or Laravel application: a 30-day playbook

The short answer

If your company has inherited an old PHP or Laravel application, do not start by rewriting it. Start by making it observable. In the first 30 days, understand what is running, reduce immediate production risk, document the critical workflows, identify unsupported dependencies, create a reliable development and staging environment, and build a realistic modernisation roadmap.

1. 01Days 1–5Gain access and create an inventory of code, servers, and integrations.
2. 02Days 6–10Stabilize production, backups, monitoring, and deployment.
3. 03Days 11–15Map the business-critical workflows and the rules that must not change.
4. 04Days 16–20Assess PHP, Laravel, packages, the database, and background jobs.
5. 05Days 21–25Fix the highest-risk issues, starting with the ability to recover.
6. 06Days 26–30Produce a phased modernisation roadmap: upgrade, selective refactor, or rewrite.

You need to know what the application does, what can break, and how to recover before you change the architecture.

Why legacy application takeovers are difficult

The code is rarely the only problem. A business may have used the same custom PHP system for eight or ten years. In that time it may have accumulated undocumented database rules, manually copied libraries, cron jobs, payment callbacks, email scripts, server-specific configuration, file-storage conventions, admin shortcuts, hard-coded credentials, special customer logic, forgotten integrations, old developer accounts, and reports used only once a quarter.

The application can look simple from the outside while carrying years of business knowledge. A new team can break a legacy system while writing technically cleaner code. The hidden challenge is understanding what must not change.

Common situations that lead to a takeover

The original developer disappeared

The freelancer or developer who built the system is no longer available. Nobody knows how deployment works, where the backups are, which cron jobs run, which server credentials are current, or why some unusual code exists.

The internal developer left

The company relied on one employee. After that person leaves, management discovers that operational knowledge was concentrated in one individual.

The current vendor has stopped responding

The software still works, but bug fixes take weeks and the relationship has become a risk.

The application runs on an old PHP version

The hosting provider wants to upgrade the runtime, and nobody knows whether the application will survive the change.

The Laravel version is no longer supported

The application may still be stable, but the framework's bug-fix or security window has passed.

The business has outgrown the architecture

What began as an internal tool now supports customers, payments, reporting, or multiple branches.

The company wants to add AI, APIs, or mobile apps

New features are difficult to add because the underlying application is poorly understood.

Why 2026 is a critical year for older PHP applications

PHP is actively maintained, but older branches have finite support windows. These dates match PHP's published support table and Techimpace's end-of-life calendar, last checked on 25 September 2026.

Laravel follows its own lifecycle. Laravel 13, released 17 March 2026, is the current major release and requires PHP 8.3 or newer; its security support runs until 17 March 2028. Laravel 12 stopped receiving bug fixes on 13 August 2026 and receives security fixes until 24 February 2027. Laravel 11's security support ended on 12 March 2026.

Do not change the runtime before you understand the application

One of the most common legacy failures starts with a hosting change. Someone switches PHP 7.4 to PHP 8 and assumes the application will keep working. Instead, authentication fails, deprecated functions break, payment callbacks stop, PDFs no longer generate, scheduled jobs fail, old packages throw errors, or date calculations change. The application partly works, which makes the problem harder to detect.

A successful homepage does not prove the system works. A business application has to be tested through the workflows that generate value.

What the 30 days are for

The exact timeline depends on the size of the system. Thirty days is a useful frame for creating control, not for finishing modernisation. By the end of the month you should have reliable access, known infrastructure, recoverable backups, documented critical workflows, identified technical risks, a prioritized remediation list, and a modernisation roadmap.

Days 1–5: gain control before changing code

The first five days are about access and inventory. Do not refactor, redesign, or clean up code because it looks old. First, determine what exists.

1. Collect all access

• Source-code repository, production server, staging server, and database.
• DNS, domain registrar, cloud account, and object storage.
• Email, payment gateways, SMS, analytics, and third-party APIs.
• CI/CD, monitoring, and app-store accounts where they apply.

If the code is not in Git, create a controlled repository after confirming which production copy is current.

2. Identify the real production stack

• Operating system, web server, PHP version, and PHP extensions.
• Framework, Composer version, database type and version.
• Redis or cache, queues, cron jobs, and file storage.
• SSL, CDN, and cloud provider.

3. Take a production snapshot

Before changing anything, capture a database backup, the application files, uploaded files, environment configuration, scheduled tasks, and server configuration where you can. Then confirm the backups can actually be restored. A backup you have never tested is only a theory.

4. Inventory integrations

5. Freeze unnecessary feature work

During the takeover, do not mix urgent stabilization, new features, a redesign, and a major refactor. You need a reliable baseline. Feature requests can continue later.

Days 6–10: stabilize production

6. Verify backups and recovery

• Database and file backup frequency, retention, and off-site storage.
• The restore procedure, and who can start a recovery.
• For transaction-heavy systems: how much data the business can afford to lose.

7. Add monitoring

At minimum, watch uptime, server resources, application errors, failed jobs, disk usage, database health, and SSL expiration. Add centralized error tracking where it fits. The goal is to know when something breaks before a customer reports it.

8. Audit privileged accounts

Find old employee accounts, shared SSH credentials, shared database passwords, unused admin accounts, and API keys owned by people who have left. Rotate critical credentials carefully. Do not rotate them blindly without knowing which services depend on them.

9. Separate development from production

If developers change the live server directly, stop that practice. Establish a path from local or development, through staging, to production. Even a basic staging environment reduces takeover risk.

10. Document deployment

• How code reaches production, and whether deployment is manual.
• Which directories are writable, and whether migrations run.
• Whether queues are restarted and cache is cleared.
• Whether there is a rollback.

Write the current process before you redesign it.

Days 11–15: understand business-critical workflows

This is where many technical audits fail. Developers review code and do not understand the business. That is dangerous.

11. Interview the people who use it

Talk to operations, finance, administrators, support, sales, and management. Ask what would stop the business if it failed tomorrow. A dashboard can be unimportant. A CSV export created every Friday can be essential.

12. Build a critical workflow map

A customer order might run from login, to creating the order, calculating tax, processing payment, generating an invoice, sending email, and updating an ERP. Every step can involve different code and external services. Map them.

13. Identify hidden business rules

• Special discounts and customer-specific pricing.
• Approval thresholds and manually overridden statuses.
• Financial rounding, tax handling, and permission exceptions.
• Date cutoffs that only matter at month or year end.

These rules are often undocumented. They are also why a clean rewrite can produce incorrect results.

14. Create regression scenarios

For each critical workflow, define cases you can repeat. Authentication: valid login, invalid login, password reset, a suspended user, and role restrictions. Payments: success, failure, a duplicate callback, a refund, and a cancelled transaction. Reports: date filters, totals, export, and permissions. You do not need complete automated coverage in 30 days. You do need a repeatable way to confirm that important behaviour still works.

Days 16–20: assess the technology

Once you understand the business, inspect the code with that context.

15. Identify the PHP and framework upgrade path

• Current and target PHP versions, and any required intermediate hops.
• Current Laravel or other framework version.
• Package, PHP extension, and hosting compatibility.

Do not pick the newest version only because it is newest. Choose a target the entire stack can support.

16. Run dependency analysis

Review composer.json and composer.lock, abandoned packages, manually copied libraries, packages without recent maintenance, security advisories, and incompatible version constraints. In a Laravel application, a package is often the real blocker.

17. Search for high-risk code

• Raw SQL built from user input, and unsafe file uploads.
• Hard-coded credentials, custom authentication, and custom encryption.
• Direct shell execution and unserialization of untrusted data.
• Outdated payment SDKs and insecure password handling.

Do not try to rewrite everything. Rank findings by business risk.

18. Review database health

Look for missing indexes, oversized tables, duplicate data, inconsistent foreign keys, old temporary tables, long-running queries, unusual triggers, stored procedures, and encoding or collation problems. The database may be the most valuable part of the application. Treat it carefully.

19. Inspect cron jobs and queues

Legacy systems often depend on background tasks that never appear in the interface: daily reports, subscription renewals, email reminders, cleanup jobs, data synchronization, and payment reconciliation. A plan that ignores them can look successful until the next scheduled run.

20. Create a risk register

Days 21–25: fix the highest-risk issues

Now you can change the system. The order matters.

Priority 1 — recoverability

Fix backups, the restore process, the repository, deployment, and access control. If a later change goes wrong, you must be able to recover.

Priority 2 — unsupported or exposed components

Address unsupported PHP, an unsupported framework, vulnerable packages, exposed admin endpoints, outdated payment libraries, and unsafe file uploads. PHP's support policy gives each release a finite active and security window, so runtime age is an operational risk, not a cosmetic one.

Priority 3 — production instability

Fix recurring errors, memory exhaustion, failed queues, timeouts, slow queries, and broken jobs. Do not spend the first month rewriting code that users never touch while production errors happen every day.

Priority 4 — critical regression coverage

Automate or document tests around authentication, payments, billing, permissions, core create-and-update workflows, reports, and integrations. Testing is what makes the later modernisation safe.

Days 26–30: choose upgrade, refactor, or rewrite

Only now should you answer whether to upgrade, refactor, or rewrite. Not before.

Upgrade the existing application

Choose this when the workflows are still correct, the architecture is understandable, the dependencies can be modernised, performance is acceptable, and users are satisfied with the core product. The work is a PHP upgrade, a Laravel upgrade, dependency replacement, security fixes, test coverage, and deployment automation. This is often the lowest-risk route.

Selective refactoring

Choose this when most of the application works and a few modules create most of the problems. Typical targets are the payment module, authentication, reporting, an API layer, file storage, or one fragile workflow. You can modernise without a full migration.

Full rewrite

Choose a rewrite only when the evidence supports it: the architecture cannot support the required workflows, the framework is deeply obsolete, technical debt prevents safe change, the business requirements have fundamentally changed, the data model is unsuitable, or maintaining compatibility costs more than rebuilding. A rewrite still has to migrate users, data, permissions, integrations, reports, business rules, and historical records. The old system usually cannot disappear on launch day.

Modernise in phases

1. 01Phase 1 — stabilizationBackups, monitoring, access, and urgent bugs.
2. 02Phase 2 — platform upgradePHP, Laravel, and dependencies.
3. 03Phase 3 — engineering foundationTests, continuous delivery, coding standards, and documentation.
4. 04Phase 4 — targeted refactoringThe modules that cost the most to maintain.
5. 05Phase 5 — product evolutionNew APIs, a mobile app, AI features, or a UX change, after the base is stable.

Phasing produces value earlier and reduces migration risk.

What the first 30 days should deliver

• A technical inventory: runtime, framework, database, servers, dependencies, and integrations.
• An access register that says who controls what.
• A backup and recovery plan, including a restore that has been tried.
• A critical workflow map of what the application must keep doing.
• A prioritized risk register.
• A compatibility assessment for PHP, Laravel, packages, and infrastructure.
• A short-term remediation list of what must be fixed immediately.
• A modernisation roadmap for the next 3 to 12 months.
• A delivery model: a fixed project, a dedicated team, or phased support.

What not to do during a takeover

• Do not rewrite because the code looks ugly. Old code can still encode valuable business logic.
• Do not upgrade production first. Use staging.
• Do not delete code that looks unused. Quarterly or annual processes can look idle.
• Do not redesign the database casually. Historical data often depends on assumptions nobody remembers.
• Do not replace an integration without reconciling behaviour. A new API can return slightly different results.
• Do not combine every new feature with the modernisation. Separate maintenance risk from the product wish list.

How much a legacy PHP modernisation costs

There is no responsible universal price. Cost depends on application size, the current PHP and framework versions, package health, test coverage, the number of integrations, database complexity, deployment, documentation, required downtime, and security requirements. A small Laravel application can be assessed and upgraded relatively quickly. A ten-year-old custom PHP system with payments, scheduled jobs, and hundreds of tables is a different project. A credible partner begins with an assessment before promising a full modernisation price.

Freelancer or a software company?

A strong freelancer can handle many PHP projects. A company becomes more useful when the application needs senior PHP and Laravel engineering, database work, QA, DevOps, frontend, cloud, security, and coordination. The larger question is continuity. If the application became risky because knowledge lived in one person, replacing that person with another single point of failure does not solve the problem.

What US companies should ask before handing the application over

1. 01How will you secure production access?Least privilege, named accounts, and a record of who can reach production.
2. 02Will you work in our Git organization?The client should retain the repository, not receive code only at the end.
3. 03What will you change in the first week?The honest answer is inventory and stabilization, not a redesign.
4. 04How will you find the critical workflows?By talking to the people who run the business, not only by reading controllers.
5. 05What is the rollback strategy?Including a restore that has been tested, not only a backup file.
6. 06How will you handle customer data, payments, and support after launch?Ask who the technical lead is, and what happens if that person leaves.

A good partner should be comfortable spending time understanding the system before proposing a rewrite.

What UK companies should check

If the partner can access personal data covered by UK GDPR, include data access and international transfers in the takeover plan. That affects production database access, anonymized staging data, logs, backups, support access, and subprocessors. Technical modernisation and data governance should be planned together.

Why companies outsource PHP and Laravel maintenance to India

Legacy maintenance needs a mix of skills that is hard to keep on staff for occasional use: PHP, Laravel, databases, QA, DevOps, cloud, and modernisation. An India-based engineering partner can put a small cross-functional team around the application without hiring every role permanently. The advantage is that capacity, not only the rate.

For companies in the United States and the United Kingdom, a practical model is a local product or business owner plus an India-based engineering team. The business keeps domain ownership. The engineering partner owns implementation and maintenance.

How Techimpace handles a takeover

Techimpace starts with an assessment, not a replacement. For a legacy takeover we look at the PHP and framework versions, the source, the database, third-party integrations, scheduled jobs, server configuration, deployment, backups, security risks, and the workflows the business cannot lose. Then we recommend one of three paths.

Stabilize and maintain

Best when the application still meets the business need.

Upgrade and selectively refactor

Best when the system is valuable and the technical debt is growing.

Rewrite in phases

Best when the current architecture no longer fits the business.

The existing PHP series covers how to upgrade an old project, how to choose upgrade versus rewrite, and how to test a release. This playbook is the operational starting point for a company that inherited an application it did not build.

A sample 30-day deliverable

A useful final report has an executive summary of health and major risks, a picture of the current architecture, an immediate risk list, and a month-by-month roadmap. The architecture is usually a chain: browser, Nginx or Apache, PHP or Laravel, MySQL, Redis or a queue, then third-party APIs.

• Immediate risks often include an unsupported runtime, no tested restore, an old payment package, shared production credentials, and no regression tests.
• A usable roadmap might stabilize in month one, upgrade PHP and the framework in month two, replace risky dependencies in month three, improve deployment and testing in month four, and refactor selected modules after that.

Legacy PHP takeover checklist

Before you approve a modernisation programme, confirm each of these.

• Source code is under version control, and production access is documented.
• A current database backup exists, and the restore process has been tested.
• The PHP version and the Laravel or other framework version are known.
• Composer dependencies, cron jobs, and payment or API integrations are listed.
• Critical workflows are documented, and a staging environment exists.
• Production errors are monitored, and security risks are prioritized.
• Deployment is documented, rollback is possible, and the modernisation route is based on evidence.