Modernize Your PHP Monolith, Without a Big-Bang Rewrite

Almost never, and certainly not as a first move. A full rewrite means running two systems in parallel, freezing product work, and rediscovering years of undocumented business rules that exist only in the current code. The parts of a PHP monolith that actually hurt are usually a small subset: a few workers, a couple of endpoints, one integration that fans out. Moving those to Go while the monolith keeps serving everything else gives you most of the benefit for a fraction of the risk. If the rest of the system is stable and cheap to run, leaving it in PHP is the correct engineering decision rather than a compromise.

When the workload profile is the problem, not the code quality. Go earns its place where you need many concurrent in-flight operations inside one process, long-lived connections, predictable memory under sustained load, or a single static binary that starts in milliseconds. The request-per-process model that PHP is built around makes those workloads expensive, because you scale by adding processes and every process carries a full interpreter and framework boot. Good candidates are queue consumers, fan-out API aggregation, streaming and data pipelines, and latency-sensitive services with a tight p99 budget. If the bottleneck is a missing index or an N+1 query, Go will not fix it: it will run the same bad query faster.

Yes, and that is usually the end state rather than a transition phase. The two sides communicate over the same boundaries you would use for any service: HTTP or gRPC calls, a shared queue such as Redis, RabbitMQ or SQS, or events on a topic. In practice the monolith stays the system of record and the Go component takes over one job behind a clear contract. Sharing a PostgreSQL or MySQL schema directly is workable early on but should be treated as temporary, because two writers on one schema removes the boundary you were trying to create. Deployment stays separate, so the Go component can be rolled back without touching PHP.

Often that is the whole engagement. Upgrading the runtime to a current PHP 8.x release, replacing an abandoned framework layer, configuring OPcache and preloading properly, fixing the queries that dominate database time, and putting real caching in front of expensive reads will frequently produce a larger improvement than any rewrite, for a fraction of the cost. It also leaves you with one system to operate instead of two. I would rather tell you that your PHP is fine and your database needs attention than sell you a migration you do not need.

No. Extracting a workload is not the same as adopting microservices. What usually makes sense is a monolith plus a small number of services that exist for a concrete operational reason: independent scaling, isolation of a risky workload, or a genuinely different runtime profile. A fleet of small services brings distributed transactions, new network failure modes and per-service operational overhead, and teams that go there without platform capacity generally regret it. If you cannot name the reason a component must deploy and scale on its own, it belongs in the monolith.

By never making the cutover a single irreversible event. The Go implementation ships alongside the PHP one and traffic moves behind a flag: shadow first, where the new path runs and its output is compared but not used, then a small share of real traffic, then the rest. The baseline metrics collected before any code changes are what tell you whether the new path is genuinely better rather than just newer. Every step keeps the PHP path deployable, so a rollback is a flag change instead of a redeploy. For queue consumers this is easier than it sounds: both consumers run against the same queue and you shift the share of messages each one takes.

Yes, and Symfony is usually the easier case. The framework pushes teams toward explicit boundaries such as dependency injection configuration, Messenger transports and console commands, and those map cleanly onto workloads that can be lifted out. Messenger handlers are frequently the first thing worth moving, because the message contract already exists and only the handler changes. Doctrine mappings are also useful as documentation of the schema when the domain model is not written down anywhere else.

Yes. Laravel systems tend to have more behaviour wired through framework conveniences such as facades, Eloquent models carrying domain logic, and queued jobs that reach into the container, so the first step is mapping what a job actually touches before deciding whether it can leave. Horizon queues and scheduled commands are the common extraction candidates. Where the boundary turns out to be unclear, it is often cheaper to restructure inside Laravel first and revisit the migration question afterwards.

Discovery has a fixed price: the migration readiness audit is €1,200 and produces an architecture review, a PHP versus Go decision matrix, a risk map and a proposed sequence. Implementation is €550 per day and is scoped after that audit, because before discovery any number would be invented. I do not quote a fixed price for rewriting a monolith, because fixed-price rewrites are how both sides end up arguing about scope instead of doing engineering. Most engagements start with a single workload, which is a small enough commitment that you can stop there if the results do not justify continuing.

That is the intended arrangement. Your engineers hold the expensive knowledge, which is the business rules and the failure history of the system, while what I add is migration experience and the capacity to do the extraction without stalling your roadmap. In practice that means working in your repository, your review process and your tracker, pairing with whoever will own the Go component afterwards, and writing the decisions down so the pattern can be repeated without me. An engagement that leaves your team unable to maintain the result has failed, even if the code works.