Do Classic ASP and PHP migrations need the same plan?

Classic ASP and a PHP monolith can render similar pages, query the same database, and irritate the same engineering team. That does not make them the same migration. Classic ASP usually arrives on the portfolio agenda because the Windows and IIS stack beneath it has become hard to host, patch, staff, or move. A PHP monolith can run on a supported stack and still be expensive to change because its boundaries exist only in developers' heads.

Treating both as generic legacy web applications produces a generic plan: inventory pages, choose a framework, convert code, test, and cut over. That sequence hides the risk that actually decides each project. With Classic ASP, the first obligation is to reproduce a fading runtime environment and its undocumented dependencies before the current host disappears. With PHP, the first obligation is to decide which architectural seams deserve to exist, because a line by line rewrite can preserve every reason the monolith is painful.

The distinction changes what you inspect, what you freeze, what you redesign, and what counts as evidence. It also explains why one fixed price migration package rarely fits both systems, even when their line counts look close.

Classic ASP carries a platform deadline

A Classic ASP migration starts with the host because the application is partly an IIS configuration that happens to have source files. ASP pages depend on the Windows scripting engines, COM registration, IIS metabase or applicationHost.config settings, 32 bit compatibility, ODBC data sources, file permissions, locale, and often an SMTP or scheduled task setup that never entered version control. Copying the .asp files gives you only the visible layer.

Microsoft's IIS documentation describes Classic ASP as an optional web server feature, disabled unless an administrator installs it. That detail sounds mundane, but it captures the risk: the runtime is an operating system role with machine state, not a dependency restored from a project manifest. The same documentation notes security changes such as disabled parent paths in newer IIS configurations. I agree with the safer defaults, but a migration team must record the old behavior before changing it or it will confuse a platform difference with an application defect.

The deadline is rarely a single vendor support date. It is the accumulated point at which the organization can no longer rebuild the server confidently. Ask whether a clean machine can be configured from recorded instructions, whether the COM installers still exist, whether anyone knows which identity owns the upload directory, and whether the database driver is supported on the intended Windows version. If those answers are weak, the hosting deadline already exists even if the current machine still responds.

This is why a Classic ASP assessment begins with a rebuild exercise. Capture the IIS site and application settings, installed roles, handler mappings, application pool properties, COM class identifiers, DSNs, certificates, scheduled jobs, Windows services, registry entries used by the application, and ACLs on every writable directory. The useful unit of inventory is an executable dependency, not a page.

Run that exercise under the identities the application really uses. An administrator testing interactively can read a registry value, instantiate a component, and write to a share that the application pool identity cannot touch. Record the bitness of the process and each native component as well. A 32 bit COM DLL may register successfully on a 64 bit server yet remain invisible to the worker process that needs it. These failures look like application bugs from the browser and like hosting defects from the server, which is exactly why the rebuilt environment needs a controlled request corpus.

Do not let a successful home page become the proof of compatibility. Exercise uploads, report exports, password recovery, end of day jobs, unusual characters, large result sets, and any route that creates a document or calls another machine. Old web systems concentrate their hardest dependencies in low traffic administrative paths. Those paths can remain untouched during a superficial test and then block the first finance or support task after cutover.

A PHP monolith carries a change-cost problem

A PHP monolith needs an architecture decision when business changes cross too much code, not merely when its PHP version looks old. Supported PHP, a current web server, and repeatable deployment can remove runtime urgency while leaving a system where checkout code includes tax rules, reports instantiate database connections, and a shared include changes authentication for every route. Upgrading the interpreter is maintenance. Redrawing those boundaries is modernization.

Teams often propose a framework upgrade as if it creates architecture. It does not. Moving global state into a dependency injection container can produce tidier syntax while preserving the same coupling. Replacing one active record library with another can leave transaction ownership ambiguous. Splitting controllers into services can create folders without creating independently testable behavior. The popular recommendation is attractive because tools can automate some syntax changes and the diff looks productive. It is wrong when the cost comes from business logic that has no stable ownership.

Find the change paths instead. Review recent work and trace what developers had to touch for a price rule, customer field, permission, or report. Identify tables written by unrelated modules, session values treated as a hidden API, includes with side effects, and jobs that call web code under a different entry point. Those connections tell you where a target boundary can reduce future change cost. A raw file count cannot.

A PHP system may also have a runtime deadline, especially if it sits on an unsupported interpreter or depends on abandoned extensions. That still does not collapse the two cases into one. Remove immediate runtime exposure with the smallest safe upgrade you can prove, then decide architecture against observed change patterns. Combining emergency compatibility work with a broad redesign makes failures harder to localize.

Measure change cost with evidence the engineering organization already has. Pull a sample of completed tickets and map each one to files, tables, jobs, and deployment units touched. Review incidents caused by changes in apparently unrelated modules. Examine how long reviewers spend reconstructing side effects and how often a release needs coordination between teams. You do not need a synthetic coupling score. You need a map that explains why a modest request travels through authentication, billing, reporting, and a shared utilities directory.

That map also prevents an expensive category error: extracting the code that looks old instead of the capability that changes badly. A stable, ugly report may deserve no redesign. A newer module that owns no data and reaches through six shared services may deserve attention first. Modernization earns its cost by changing the economics of future work, not by making every file look contemporary.

The inventories answer different questions

The Classic ASP inventory asks, "What must exist for this request to run exactly as it does now?" The PHP inventory asks, "What must change together, and why?" Both inspect code, configuration, data, traffic, and operations, but they weight the evidence differently.

Do not merge these into one spreadsheet with columns for file name, language, and complexity. That format creates false comparability. A five line ASP call into a proprietary COM component can control the whole schedule. A five thousand line PHP controller may be verbose but mechanically separable. Rank Classic ASP dependencies by rebuild and replacement risk. Rank PHP areas by coupling, change frequency, and business ownership.

There is another distinction teams blur: dependency discovery is not architecture discovery. Dependency discovery finds what the system needs to execute. Architecture discovery finds which responsibilities should be allowed to change independently. Classic ASP demands the first before the host changes. PHP modernization gains most of its value from the second. Each project needs both eventually, but the order and depth differ.

Recorded behavior is the common ground

Both migrations need a behavior baseline before engineers rewrite anything, because source code is an incomplete specification. Production traffic exposes parameter combinations, cookie states, redirects, content types, encodings, error responses, and timing assumptions that code review misses. Database snapshots, generated files, outbound messages, and job results add the effects that HTTP responses cannot show.

Record representative requests with sensitive values removed or replaced, then replay them against the old and new systems in a controlled environment. Compare status, headers that matter to clients, normalized bodies, database changes, files, and outbound events. Do not compare every volatile byte. Timestamps, request identifiers, ordering that has no contract, and CSRF tokens need explicit normalizers. Every normalizer should have an owner and a reason, because an overbroad normalizer can erase a real regression.

A useful parity case is an object with both the stimulus and the expected observable effects:

{
  "case": "invoice-posted-with-credit",
  "request": {
    "method": "POST",
    "path": "/billing/post.asp",
    "form": {"invoice_id": "18421", "apply_credit": "1"}
  },
  "expect": {
    "status": 302,
    "location": "/billing/view.asp?id=18421",
    "database": ["invoice.status=posted", "credit.remaining=0"],
    "outbound": ["invoice-posted email"]
  }
}

The exact harness will differ, but its output must identify the case, the differing observation, the old value, and the new value. "Test failed" is not enough for migration work. An engineer must be able to tell whether a redirect changed, a decimal rounded differently, or an email was sent twice.

For Classic ASP, recorded behavior protects against runtime differences such as date parsing, code pages, Variant coercion, and COM return values. For PHP, it protects the team while it moves logic across new boundaries. The mechanism is common; the reason for using it is different.

Coverage matters more than raw request volume. Build cases around business states and transitions: a first purchase and a repeat purchase, an expired entitlement, a partial payment, a user with two roles, a report crossing a daylight saving boundary, and a retry after a downstream timeout. Then connect each case to the production traffic that proves its request shape is real. Thousands of duplicate successful GET requests add less confidence than one recorded reversal with verified database effects.

Keep the old system available as an oracle only while you understand its limits. The old result may contain a defect that users now depend on, or a defect the migration should intentionally remove. Mark intentional differences as reviewed decisions with an owner and a new expectation. Do not hide them in a normalizer. A parity harness should expose every difference, then let people classify it; it should never silently define the old system as correct.

Classic ASP sequencing removes host risk first

A sound Classic ASP plan makes the existing behavior portable before it makes the design elegant. The sequence should expose machine state early and retire it deliberately.

1. Rebuild the application on a clean, supported Windows and IIS environment from written configuration and retained installers. Log every manual action that the source repository cannot reproduce.
2. Capture and replay representative production behavior on both the current and rebuilt hosts. Resolve compatibility differences before introducing a new application architecture.
3. Replace or wrap dependencies that cannot survive the move, starting with COM components, obsolete database providers, and machine local storage. Give each replacement its own parity cases.
4. Rewrite bounded behavior into the target runtime while the old application remains available as the oracle. Route controlled traffic to the new path and compare effects.
5. Cut over only after operations can deploy, restore, observe, and roll back the new system without access to the original machine.

This order may reveal that a temporary IIS landing zone is necessary. That is acceptable if it is explicit, reproducible, patched, and has an exit condition. It is not modernization to move an opaque virtual machine into a different data center and declare victory. The temporary host buys time to remove machine dependencies; it should not become the permanent plan by inertia.

Avoid redesigning every workflow while you still cannot explain how the old host executes it. When a rewritten invoice page differs from production, you need to know whether the cause is a changed business rule, a locale setting, an ADO provider behavior, or a COM call. Separating environment parity from design change cuts that search space.

PHP sequencing creates and tests boundaries

A sound PHP plan starts with a target boundary tied to real change pressure, then moves behavior through that seam. The original monolith can remain on a supported host while the team proves one domain boundary at a time. A complete rewrite behind closed doors removes the feedback that should shape the design.

Choose boundaries from business ownership and transaction needs, not nouns discovered by scanning table names. "Customer" appears everywhere and rarely makes a useful first service. A pricing decision, document generation flow, entitlement check, or settlement process often has a clearer input, output, and owner. Keep work that requires one atomic database transaction together until you have a deliberate strategy for consistency. Network calls do not improve a design simply because they cross a process boundary.

The first extraction should prove the architectural mechanism: how callers authenticate, how contracts evolve, who owns data writes, how retries avoid duplicate effects, how failures surface, and how the old path falls back. It also needs evidence that the boundary reduces change scope. If every feature still requires edits on both sides, the team has created distribution without independence.

Do not require microservices. A modular monolith in Go or TypeScript can make ownership and dependency direction explicit with much less operational cost. Rust may fit a numeric kernel where overflow, precision, and throughput deserve tight control, but using it for ordinary request plumbing adds a language boundary without solving a domain problem. The target architecture should remove the coupling you measured, not display the organization's preferred technologies.

Data ownership decides whether the split is real

A migration has not created a boundary if the new component and the old application can update the same tables whenever convenient. Shared reads can be a temporary bridge. Shared writes create two sets of invariants, two transaction models, and no reliable owner when values disagree. This risk exists in both systems, but it becomes central during PHP architectural work because extraction invites premature database sharing.

Start by naming the writer for each business fact. If the new pricing module owns a calculated quote, the monolith may request the calculation and store an immutable reference, or the module may own the quote record and expose it through a contract. Either can work. Letting both recalculate and overwrite the amount cannot. Record which side validates transitions, assigns identifiers, and publishes effects.

Classic ASP often hides data behavior in stored procedures, triggers, and ADO defaults. A page rewrite that preserves SQL text may still change parameter types, null handling, cursor behavior, or transaction scope. Run parity checks at the database effect level, especially for money, dates, and multirow updates. Do not assume a matching HTML response proves a matching operation.

PHP monoliths often hide the same problem behind an ORM. Model callbacks, lazy loads, global scopes, and implicit transactions can turn a simple method call into several effects. Before moving the method, capture the queries and resulting state, then decide which effects belong inside the new boundary. Reproducing every callback blindly is transliteration. Dropping them blindly is data loss.

Plan the transition state, not only the desired endpoint. If the old code must read data owned by the new component, prefer an explicit compatibility view, API, or replicated read model with a removal date. If both paths must receive the same command during a trial, designate one as authoritative and compare the other's proposed effects without committing them. Dual writes from application code look easy on a diagram, but partial failure turns them into a reconciliation system. Most teams do not want to build and operate that system for a temporary migration bridge.

Schema changes need the same discipline. Add fields and readers before changing writers, tolerate old and new representations during the transition, and remove compatibility only after traffic shows the old path is gone. The database deployment and application deployment may not be atomic. A plan that assumes they are will eventually meet a rollback in the wrong order.

Sessions, jobs, and files expose the hidden application

The request and response path is usually less than the whole system. Classic ASP applications may use InProc session state tied to an IIS worker, write generated documents to a local directory, accept uploads that another Windows task consumes, or invoke a COM object that sends mail. PHP monoliths may have cron jobs that bootstrap the web application, queue workers with different environment variables, shared sessions, and files treated as a coordination mechanism.

Session migration deserves an explicit choice. You can preserve the cookie and session representation, bridge lookups between old and new runtimes, or force users to sign in again at a planned cutover. The correct choice depends on security and user impact. Pretending sessions will carry across automatically is not a choice. Test expiry, rotation after authentication, concurrent requests, logout, and deployment restarts.

Jobs need their own traffic corpus. Record inputs, schedule rules, locking behavior, database effects, generated files, and retry behavior. A job that succeeds when run manually can still duplicate invoices when two schedulers overlap. A queue consumer can return no HTTP response yet carry the most damaging business logic in the application.

Treat file paths as interfaces. Identify who writes, who reads, naming rules, retention, encoding, atomicity, and what happens after a partial write. Moving from a local Windows directory or shared PHP host to object storage changes consistency and permissions. Model that change rather than replacing a path string and hoping every consumer behaves.

Acceptance gates must prove the dominant risk

A shared status dashboard can track both projects, but the release gates should not be identical. Classic ASP gates should prove that the organization has escaped the old host. PHP gates should prove that the new design reduces coupling without changing behavior. Counting converted files or passing unit tests does neither.

For Classic ASP, require a clean environment build from controlled artifacts; a complete inventory with an owner and disposition for each external dependency; parity results across representative interactive and batch behavior; operational evidence for deployment, backup, restore, monitoring, and rollback; and a test showing that the old server can be unavailable without removing an installer, secret, certificate, or source of truth that the new service needs. Decommission readiness is an acceptance property.

For PHP, require an explicit contract for each new boundary; one writer for each moved business fact; parity at responses and side effects; dependency rules enforced in code or build checks; failure and retry tests at process boundaries; and evidence from completed changes that work inside the extracted area no longer requires unrelated monolith edits. Architectural independence must show up in the change path.

Performance comparisons also need context. Match production request shapes and concurrency, warm the relevant caches, and compare database work as well as latency. A new endpoint can return quickly while pushing expensive work into a queue that cannot keep up. A rewritten report can look fast against an empty copy of the database and fail at month-end volume. Use the load and data distribution the business actually has.

Define failure budgets for migration mechanics too. How many parity differences may remain open, which severity blocks traffic, how long may a queue lag, and what database reconciliation must equal zero? State who can waive a gate and how that decision is recorded. Without those rules, a deadline converts unexplained differences into accepted risk through meeting fatigue. With them, executives can see whether the remaining work concerns harmless presentation details or uncertain financial effects.

Rehearse rollback at the same boundary used for rollout. If routing moves one capability at a time, prove that it can return independently without losing writes completed on the new path. If cutover moves the whole application, measure the restore and data reconciliation procedure on production shaped data. A rollback document that has never been executed is a hypothesis, not an operational control.

One estimate cannot express both uncertainties

An estimate for Classic ASP should expose unknown host dependencies, replacement choices, and the amount of behavior evidence available. An estimate for a PHP monolith should expose boundary decisions, shared data ownership, and the cost of changing callers. A vendor who prices both from line count and page count has measured typing, not migration risk.

Ask a Classic ASP team to demonstrate a clean rebuild and show how it discovers calls outside the repository. Ask what happens to each COM object, DSN, scheduled task, certificate, and writable directory. Ask how it will compare old and new behavior when Variant conversion or locale changes a result. A proposal that begins with automated source conversion but cannot answer those questions begins too late in the stack.

Ask a PHP team to draw the proposed ownership boundary and walk a recent feature through it. Ask which component writes each table, how an operation remains idempotent after a retry, and what evidence would cause the team to keep a modular monolith instead of splitting a service. A proposal that promises microservices before studying transactions has chosen the diagram before the system.

Contract structure should follow evidence. Discovery needs concrete outputs: a dependency register, behavior corpus, boundary map, target decisions, and acceptance gates. Delivery milestones should correspond to retired risks or working behavior, not percentages of files converted. Fixed dates do not make unknown dependencies disappear; they make early discovery and narrow decisions more important.

The estimate should separate known implementation from explicit options. Replacing a particular COM component can have one price after the team has observed its inputs and outputs. Deciding whether a PHP capability belongs in the monolith, a module, or a service is an architecture option with consequences for deployment and data ownership. Mixing both into a single contingency percentage conceals which decision could change the work.

Require assumptions to be falsifiable. "Standard ASP application" and "typical PHP codebase" say nothing. "No native component writes outside the listed directories" can be checked. "The settlement flow owns these four tables and no other code writes them" can be checked. An estimate becomes more trustworthy when the team tells you what observation would force it to change.

The right plan follows the reason for moving

Classic ASP should leave you able to turn off the old Windows host without losing behavior or an undocumented operating instruction. A PHP modernization should leave teams able to change a business capability without tracing shared state through the whole monolith. Those are different finish lines.

CodeHero handles both Classic ASP and PHP sources, reads the whole codebase and its languages together, and verifies rewritten behavior with a parity harness against recorded production traffic. Its projects modernize the architecture into Go, Rust, TypeScript, and Postgres in under 30 days, including an air-gapped deployment of its supplied models inside the customer perimeter when the environment requires it.

Even if you use another team, insist that its plan names the dominant risk in the first page. For Classic ASP, demand evidence that the host can be reconstructed and then removed. For PHP, demand a defensible account of ownership, transactions, and the change paths the new architecture will shorten. If one template answers both, it has probably answered neither.