The Web System Your Business Runs On Was Built Before Half the Industry Learned to Code.
Legacy web application support for systems younger developers cannot maintain.
Somewhere in your operation is a web-based system that has been running for 5, 10, maybe 15 years. An ecommerce platform with custom inventory logic. A portal built in PHP before frameworks were a given. A Drupal build from the 6 or 7 era that still handles a meaningful part of the business. A custom application the original developer wrote in a stack that is no longer fashionable, and now nobody wants to touch it.
The standard advice is to rebuild. Pay an agency six figures to rewrite it in whatever is trending this quarter, migrate the data, retrain everyone, and hope the new version covers the edge cases the old one handled without anyone noticing.
That is sometimes the right answer. More often, it is not. The system works. The business depends on it. What it needs is someone who can actually read the code, understand why it was built that way, and either stabilize it for another five years or migrate it on a timeline that does not wreck operations.
That work requires the kind of experience most consultants cannot offer anymore.
What This Actually Covers
Legacy PHP and LAMP Applications
Custom systems built on PHP 5.x, 7.x, older MySQL, CodeIgniter, CakePHP, Zend, hand-rolled frameworks. Code that does not follow modern conventions because the conventions did not exist yet. Understanding it requires having written it when it was current.
Drupal 6, 7, 8, 9 Support and Migration
70–80 Drupal builds across a decade. Manufacturers, retailers, real estate portals, investment platforms, government systems, title company auditing tools, foster care tracking, casino infrastructure. Including non-standard configurations like Drupal on SQL Server. Migration planning that accounts for what custom modules actually do, not just what they are named.
WordPress Custom Application Rescue
Not theme-tweaking. Custom post types, custom plugins, WooCommerce customization at the application layer, headless configurations, multisite architecture, database-level performance work. WordPress used as an application framework, which is what it is when the build is serious.
Legacy Ecommerce Platforms
Older Magento, osCommerce, OpenCart, custom cart systems, and other platforms from the pre-Shopify era. If the platform still runs the business, there is usually a path forward. For platform-specific rescue, hack recovery, and emergency work, see Application Rescue.
Inherited Web Applications
The original developer is gone. Documentation is minimal. The code is the documentation. This is the work of reading it, understanding it, and making it maintainable, or telling you honestly when the right answer is a rebuild.
Database-Backed Web Systems
MySQL, MariaDB, PostgreSQL. Schema issues, performance collapse on growing datasets, broken migrations, query optimization, reporting layers that used to be fast and are not anymore. Large-dataset work where the problem is architectural, not cosmetic.
API Integrations for Older Systems
Wiring a legacy platform to modern services: payment processors, shipping APIs, ERPs, CRMs, marketplaces. This applies when the platform was not designed with those integrations in mind.
What This Is Not
Not general IT. No Windows Server, no Active Directory, no desktop support, no QuickBooks, no on-prem networking. The focus is the web and application layer: the systems your business runs on the internet, not the network closet.
How the Work Happens
On-demand rate: $175–$250/hour, billed in 30-minute blocks. Two-hour minimum for new engagements. Remote work begins immediately once access is arranged.
Project engagements for larger scopes: legacy migrations, platform rebuilds, and application modernization projects are structured as monthly engagements at $3,500–$8,500/month over a defined 3–6 month period. Total cost is predictable before work begins.
Honest assessment. Not every legacy system needs to be rescued, and not every old system needs to be rebuilt. If the right answer is “migrate this, here is the path,” that is what I will tell you. If the right answer is “this can run reliably for another five years with some targeted work,” that is what I will tell you.
Why Rofsky
25 years of direct technical work on the web and application layer. Started in 2001, which means the “legacy” systems most businesses are worried about were built during the span of my career, often in stacks I was actively working in at the time. PHP since version 4. MySQL since version 3. Drupal since version 5. WordPress since the early plugin API era. Ecommerce customization going back to eBay integrations before marketplace APIs existed.
What that means in practice: the kinds of legacy systems that stump other consultants are often the ones I have seen before. The diagnostic process is systematic: code review, data integrity, performance profiling, dependency audit. Not trial-and-error.
Every engagement is handled directly. No junior developers, no offshore teams, no handoffs.
When to Call
• A custom web application your business depends on is degrading and you cannot find anyone to maintain it
• The original developer is unreachable and the code is undocumented
• You are being quoted six figures to rebuild something that might not need to be rebuilt
• A legacy ecommerce platform is still running the business and you need a path forward
• An older Drupal or WordPress build is breaking in ways nobody on your team can diagnose
• You inherited web infrastructure from an acquisition and need someone to figure out what is actually running
Common questions
- What counts as a legacy system?
- Any web system old enough that the original tooling is no longer maintained. Drupal 6 or 7. WordPress older than version 5. Custom PHP frameworks from before Composer. Flash-era applications.
- Should I migrate off my legacy system?
- Not always. If it works, serves the need, and has no security or compliance pressure, leaving it alone is often the right call. Migration is the right answer when maintenance cost is rising, security exposure is growing, or new features are impossible.
- What is a typical migration timeline?
- 3 to 9 months for a mid-size system. Phased: documentation, parallel build, data migration, testing, cutover.
- Can you maintain a legacy system without migrating it?
- Yes. Security patches, small feature additions, performance work. Retainer-based is the usual arrangement.
- What if I have lost access to the server or original developer?
- Common situation. Rofsky can recover from a backup, a database dump, or a live site scrape. Most legacy projects start this way.