LonghornPHP 2025 - So You Just Inherited a Legacy Application... .pdf

Given at Longhorn PHP 2025 in Austin, TX

1. So You Just Inherited a $Legacy
Application...
Joe Ferguson

2. leanpub.com/minimumviabletests leanpub.com/mlaphp
For Further Reading

3. Legacy
Applications

4. First:
A Warning

5. “There are no
solutions, only
trade offs”
- Thomas Sowell

6. What is a "Legacy" application
“The Princess Bride”

7. Legacy is often used for an older
production application that was
written before, or without regard
for modern technologies or
practices.

8. If you ask Wikipedia…
"... no-longer supported …"
"... maintained by an administrator that did not develop the code …"
"... supporting older file formats ..."
https://en.wikipedia.org/wiki/Legacy_code

9. Modern Interpretation
"... source code inherited from someone else …"
"... source code inherited from an older version of the software ..."

10. Some people say…
"Any code in production is not legacy”
"Any code written X years ago is legacy"

11. Legacy is all these things
"... no-longer supported …"
"... maintained by an administrator that did not develop the code …"
"... supporting older file formats ..."
"... source code inherited from someone else …"
"... source code inherited from an older version of the software ..."
"Any code in production is not legacy”
"Any code written X years ago is legacy"

12. This process is
not Legacy
Specific…

13. Inheriting a Legacy App
Precontemplation or Shock/Disbelief
Contemplation and/or Anger
Determination and Bargaining
Action and Reconstruction
Maintenance and Acceptance

14. Precontemplation
or Shock/Disbelief

15. Precontemplation
or Shock/Disbelief
This is the initial "what is this?!"

16. That’s now how this works!

17. Precontemplation
Not ready for change (project, code base, etc)
Usually you don’t know the depths of issues
Can sometimes lead to assuming the worst
Usually this is the shortest phase due to business needs

18. Shock/Disbelief
This is where the WTFs and the WTHs should be left
Try to work through any negativity here
Be positive about the previous developer’s intentions

19. Contemplation and/or Anger
This is the planning phase
Try to get all of your ager at the code base out during this phase, it will
help you see the path forward.
Taking stock of what we’re working with

20. Initial Project Overview
Is there a framework?
Is there a coding standard?
Is there any autoloading?
How are dependencies being handled?
Is there an ORM or how is the database being utilized?
Is there a development environment?

21. Is there a
framework?
Is it modern? Is it upgradeable?

22. Is there a
coding
standard?

23. No Standard? No problem! Use PSR-12

24. Is there any
autoloading?
In 2025 I would hope so, but not always!

25. There is a PSR for that…

26. How are
dependencies
behind
handled?
In 2025 I would hope via Composer, but not always!

27. Is there an
ORM?
How is the database being utilized?

28. Is there a
development
environment?
If not, start here

29. Tools to help with Code Standards
https://cs.symfony.com/

30. Tools to help with Code Standards
php-cs-fixer fix app --dry-run

31. PHPStan
https://phpstan.org/

32. PHPStan
https://phpstan.org/

33. Warning about
Automating
Code Changes

34. Composer
https://getcomposer.org/doc/01-basic-usage.md

35. Doctrine
http://www.doctrine-project.org

36. Propel ORM
http://propelorm.org
●Migrations
●Reverse Engineer your
existing DB
●Fast

37. Local Dev Environments
Physical Hardware (Somewhat uncommon outside
Academia)
Vagrant (Virtual Machines) (What year is it?!)
Docker (Containers)
K8s / K3s / Rancher (Containers)

38. Docker
Containerised your application where each part runs in isolation
App servers, DB servers, Cache Servers all isolated but interconnected
Can be orchestrated across many nodes or a single node

39. Docker For Developers 2nd Edition
https://www.phparch.com/books/docker-for-developers/

40. Determination
and Bargaining
Decision making and triage time

41. Triage
Address any critical things found in Contemplation phase
PHP version issues
Fixing critical vulnerabilities

42. You have a
plan
… now you need to estimate this plan.

43. I hate estimating; some tips:
Estimates must be based in reality of what you and the team can accomplish
Don’t short estimates to force budget constraints, cut features instead
Don’t be afraid to push back, but be reasonable
Don’t be afraid to follow minimum viable product and iterate from there

44. No Question Left Behind!
The application has no framework, We’re going to use a micro framework as
we refactor.
The application has no autoloading, But we’re using Composer
Dependencies are checked into version control, But we’re using Composer
There is no ORM, but we’re going to use Propel
We have no dev environment but we’re going to use Docker

45. Proof of Concept
Any new things introduced should be tested to ensure functionality
Build out a small example of an area you or the team doesn't fully
comprehend so you can address any questions that may arise

46. Bargaining
Getting stakeholders on board with your estimates
Do the decisions made thus far make business sense?
Are there any doubts in the plan?

47. “We should
just rewrite the
app”

48. "This would be
so much easier
in framework X”

49. Why not rewrite?
Progress halts entirely
Business logic is rarely reused
Most of the time is getting back to
current functionality

50. Why you should refactor
Progress continues
Business logic reused
Modernizing functionality instead
of recreating

51. What we’ve done so far
Made Decisions
Build Proof of Concept(s)
Ensure stakeholder buy in
Avoid the allure of green fields**
** in some cases a rewrite is warranted

52. Action and
Reconstruction

53. Existing Tests
This is great!
Review the tests to get an idea of coverage
Passing tests become your control for any upcoming changes
Confidence++

54. No Existing Tests
Not the end of the world!
Inspect the code base, was it written to be easily testable?
Could you easily mock dependencies?

55. Untestable Code
Not all code is testable
If you can’t easily unit test the code base, consider alternatives
Functional testing and Acceptance testing are valid options

56. Acceptance Testing
NOT a replacement for Unit Testing
Test large parts of your application at a time
Can be harder to pinpoint error location
Gives large code coverage in short amount of time

57. Digging into the Code
Code Consolidation

58. Digging into the Code
Code Consolidation
Replace globals with DI

59. Digging into the Code
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)

60. Digging into the Code
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)
Extract Business Logic (To domain logic)

61. Digging into the Code
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)
Extract Business Logic (To domain logic)
Extract Presentation Logic to Views (Twig, Blade, etc)

62. Digging into the Code
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)
Extract Business Logic (To domain logic)
Extract Presentation Logic to Views (Twig, Blade, etc)
Extract Action Logic (To Controllers)

63. Digging into the Code
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)
Extract Business Logic (To domain logic)
Extract Presentation Logic to Views (Twig, Blade, etc)
Extract Action Logic (To Controllers)
Write (more) tests

64. Maintenance and
Acceptance

65. Maintenance and Acceptance
Code Consolidation
Replace globals with DI
Write tests
Extract SQL (to ORM or other)
Extract Business Logic (To domain logic)
Extract Presentation Logic to Views (Twig, Blade, etc)
Extract Action Logic (To Controllers)
Write (more) tests

66. Maintenance and Acceptance
Adding Features
More New Code
Less Refactoring
Maintain your processes

67. Continuous
Integration

68. Revisit
Acceptance
Tests

69. Resources / Q & A
●Modernizing Legacy Applications In PHP - Paul M. Jones
○https://leanpub.com/mlaphp
●Minimum Viable Tests - Chris Hartjes
○https://leanpub.com/minimumviabletests
●Code Style
○https://github.com/FriendsOfPHP/PHP-CS-Fixer
○http://editorconfig.org
●Autoloading PSR-4
○https://getcomposer.org/doc/01-basic-usage.md
●ORMs
○http://www.doctrine-project.org
○http://propelorm.org
●Docker
○https://www.phparch.com/books/docker-for-developers/
○https://lando.dev/