What actually changes is narrower and more useful: the ratio of time spent on mechanical work versus decisions. On a typical enterprise commerce build, a depressing share of engineering hours goes to work that is not hard, just long — module scaffolding, transfer object definitions, data importers, test fixtures, mapping one system's vocabulary onto another's. That is where the leverage is.

The three places it pays

Boilerplate with a known shape. Spryker's module structure is highly regular: a new module means a bundle of files whose contents are almost fully determined by the domain object. Generating that from a specification and reviewing the result is faster than typing it, and the review is genuinely quick because the shape is familiar. The same applies to Symfony form types, doctrine mappings, and API resource definitions.

Migration sweeps. Applying one mechanical change across two hundred call sites is the canonical case. A deprecation, a renamed transfer property, a changed signature. The work is tedious enough that engineers batch it, defer it, and let it rot. When the sweep is cheap, it happens on schedule.

Test scaffolding. Not the assertions that matter — the fixtures, the builders, the setup that makes writing the meaningful test bearable. Teams under-test integration code because standing up the fixture costs more than the test. Lower that cost and coverage moves without anyone being told to care about coverage.

Notice what is missing from that list: the architecture, the integration contracts, the pricing rules, the decision about where a boundary goes. Those are the parts that were always the job, and they are still the job.

The review discipline is the whole product

Generated code that nobody reads is a liability with a faster clock speed. The practice that makes this work is unremarkable and non-negotiable:

• Every generated change goes through the same review as hand-written code. No separate lane, no "it's just boilerplate" exemption.
• The reviewer is the engineer who will own the code in production. Not the person who prompted for it.
• Anything touching money, tax, availability or personal data gets read line by line, twice. The cost of a plausible-looking bug in a pricing rule is not symmetric with the cost of reading it.

The failure mode is not that the model writes nonsense — modern ones rarely do. It is that it writes something reasonable that quietly disagrees with a business rule nobody wrote down. That failure is invisible to tests generated from the same misunderstanding, which is why "the tests pass" carries less weight here than it used to.

A worked example

Here is the kind of thing that looks fine and is wrong. A generated price resolver for a B2B catalog:

public function resolve(ProductTransfer $product, CustomerTransfer $customer): Money
{
    $contract = $this->contractReader->findActive($customer);

    if ($contract !== null) {
        return $contract->getPriceFor($product);
    }

    return $product->getDefaultPrice();
}

Idiomatic, typed, readable, and it will pass a review that is checking whether the code is well-formed. It is also wrong in most B2B contexts, because contract price and list price are not alternatives — the customer pays the lower of the two, and in some jurisdictions a contract price above list is not merely a bad deal but unenforceable. No amount of static analysis finds that. Someone who knows the domain reading it does, in about four seconds.

That four seconds is the job now.

What it means for an estimate

The honest version of the economics: mechanical work compresses substantially, decision work does not compress at all, and review work goes up — you are reviewing more code per unit of calendar time than before.

On builds where the mechanical share was large — a fresh Spryker implementation with many modules, or a broad integration surface — that nets out to a meaningfully shorter delivery. On builds that are mostly gnarly business rules against a legacy integration, it barely moves the total, and anyone promising otherwise is selling you an estimate rather than a plan.

The useful question to ask a supplier is not whether they use AI. It is which of their hours are mechanical, and who reads the output before it ships.

Publish & Sync: fast reads, bought on credit

The reason product pages can be fast is that the work happened earlier: an entity changes in Zed, events fire, publishers rebuild the denormalised view, and sync writes it to Redis and Elasticsearch. That pipeline is the platform's load-bearing wall, and two failure modes account for most of the grief.

The backlog. A full catalog import touches every product, which fires events for every product, which can leave the queues chewing for hours — during which the storefront cheerfully serves stale prices and yesterday's stock. If your nightly import "sometimes isn't finished by morning", this is usually what that sentence means. The fixes are unglamorous: import true deltas instead of the whole feed, batch the events, tune publisher chunk sizes, and put queue depth on a dashboard with an alert. Sync lag is invisible until a customer orders something that sold out yesterday — it deserves a metric more than most things that have one.

The over-eager publisher. A custom publisher that rebuilds too much per event — the classic is touching every abstract product in a category because one attribute changed — multiplies a small edit into thousands of writes. Reading the publisher code with the question "what is the blast radius of one event?" is a profitable afternoon on most mature Spryker projects.

Redis round trips: death by a thousand GETs

Redis answers in well under a millisecond, which tempts people into treating it as free. It is not free from PHP, because each lookup pays the full round trip. A product listing that resolves each tile's data one key at a time — product, then price, then availability, then image sets, then labels — quietly stacks up hundreds of sequential network hops, and the page spends more time waiting on the loop than on any single query.

The remedies are old-fashioned: batch key lookups (MGET) wherever a collection is being hydrated, and treat any per-item storage read inside a foreach as a code smell in review. The storage client's batch methods exist precisely for this; the sin is usually in custom code that never heard of them. The same shape applies to Elasticsearch — one query with facets and the result page, not a query per widget.

While you are in the neighbourhood, look at what is in those keys. I have seen product storage entries north of a hundred kilobytes because a publisher serialised the entire attribute universe "to be safe". You pay to build it, store it, transfer it and unserialise it, on every page, forever. Publish what the frontend reads. Nothing else.

The synchronous call hiding in checkout

Browse and search run on Spryker's fast path. Checkout is where projects smuggle in the slow one: a live ERP credit check, a real-time stock reservation, a tax service, a payment provider's session setup — each a reasonable decision, each adding a synchronous external dependency to the single most conversion-sensitive click in the shop. Three reasonable decisions later, "place order" takes nine seconds and fails whenever any one of three other systems sneezes.

The design questions worth forcing early: which of these answers must be correct at this instant, and which can be seconds stale? Stock can usually be a cached read with a reservation behind the scenes; the credit check often genuinely must be live — in which case it needs a timeout, a fallback policy agreed with finance, and a place in the order state machine for "accepted pending review". What it must never be is an unbounded wait between the customer and their confirmation page.

Measure like a customer, not like a server

The last recurring failure is measuring the wrong number. Server-side response time on a cached product page tells you almost nothing about what the customer felt — front-end weight, third-party tags and cache hit rates routinely dominate. Two habits keep the work honest: track percentiles from real-user monitoring rather than averages from synthetic checks against warm caches, and before any tuning sprint, write down the one journey that matters (usually listing → product → cart → order) with its current p95 numbers. Optimising pages nobody visits is the most popular performance work there is, because it is easier than fixing the import.

None of this is exotic engineering. It is knowing which parts of the machine carry the load, and pointing the effort there instead of at the profiler's prettiest flame graph.

The instinct — the client's and the engineer's — is to start fixing the most painful bug on day one. It is almost always the wrong first move, because in a codebase you do not understand, with no tests and no safe deployment, every fix is a coin flip that can convert "annoying bug" into "site down". Here is the sequence that has worked instead, and it front-loads a month in which embarrassingly few features ship.

Week one: make deployment boring

Whatever else is true of the system, you cannot operate it until you can release and roll back without ceremony. So the first deliverable is not a fix, it is a pipeline: reproducible builds from a clean checkout, one command to deploy, one command to roll back, and the environment configuration pulled out of the special laptop and into version control (secrets excepted, obviously).

This work is invisible to the business, so say the quiet part in the kickoff: nothing user-visible will improve for a few weeks, and this is the part of the engagement that makes every later week cheaper. Clients accept a stated trade-off far more gracefully than a discovered one.

While the pipeline work happens, resist knowledge-transfer theatre. Reading the entire codebase up front converts none of it into understanding. Instead, wire up error tracking and slow-query logging and let production tell you where the bodies are. A week of real traffic annotates the codebase better than its authors ever did — you get a ranked list of what actually breaks and what is actually slow, which is the only map worth having.

Characterise before you change

The standard objection to touching legacy code is "there are no tests". True, and unhelpful — you cannot retrofit a proper unit test suite onto code whose behaviour you do not yet know is intended. What you can do is pin the current behaviour down before changing it. Two tools carry most of the weight:

• Golden-master tests for the money paths. Drive checkout, cart totals, tax and shipping calculation through their paces with a few dozen recorded inputs and assert the outputs stay byte-identical. You are not asserting the behaviour is correct — nobody knows — you are asserting your changes did not alter it unknowingly. When a golden master breaks on purpose, that diff is the code review.
• HTTP-level smoke tests. Twenty URLs, logged in and out: status codes, a handful of load-bearing strings, response times. Crude, and it catches the class of regression that actually takes revenue down — the fatal error on a template path nobody clicked in staging.

With the pipeline and the pins in place, upgrades become mechanical instead of heroic. The Symfony jump goes minor version by minor version, deprecations cleared at each step, golden masters green at each step — tedious, low-drama work, which is the point. (This staircase of mechanical sweeps is also where AI-assisted tooling genuinely pays; the deprecation churn compresses nicely. The judgement calls on either side of it do not.)

Strangle the worst of it; keep the rest

Somewhere in month two, someone will propose the rewrite. The honest response to "this is unmaintainable" is usually "parts of this are unmaintainable" — most of the revenue is flowing through code that, however ugly, encodes years of fixes for problems you have not met yet. Throwing that away wholesale means rediscovering those problems one incident at a time.

So rescue proceeds by organ transplant, not resurrection. The genuinely rotten subsystem — in one memorable case, a homegrown "cache" that wrote serialized PHP objects to the database and was the source of a quarter of all errors — gets isolated behind an interface, rebuilt, and swapped, golden masters standing guard. The merely old-fashioned code gets left alone until there is a business reason to open it. Ugly-but-stable is not a technical problem; it is a preference, and rescues that chase preferences run out of budget before they run out of ugliness.

The success condition is worth stating because it is modest: the client can deploy on a Tuesday afternoon without holding their breath, the error tracker is quiet enough that a new entry means something, and the next developer to join gets productive in days. Not a beautiful codebase — a boring one. In legacy work, boring is the deliverable.

It doesn't have to. The business case for replatforming usually evaporates if you have to buy it with three quarters of frozen feature work, so the interesting question is never "how do we rebuild this?" — it's "how do we rebuild this while the old system keeps taking orders?"

Route traffic before you move code

The single decision that makes or breaks an incremental migration is where the routing boundary lives. Put a reverse proxy in front of both systems on day one, before a single line of the new platform exists. Every path resolves to the legacy application by default; you move paths across one at a time.

location /checkout { proxy_pass http://legacy; }
location /catalog  { proxy_pass http://spryker; }
location /         { proxy_pass http://legacy; }

That is the entire strangler pattern. It is unglamorous, and it is what turns a big-bang cutover into a sequence of reversible decisions. When the new catalog misbehaves under real traffic, the rollback is one line of config, not a weekend.

The corollary matters just as much: pick the boundary along a seam the business already understands. Catalog, search, checkout, account. If your first slice cuts across three of those, you have not found a seam — you have found a rewrite.

Sequence by risk, not by ease

The instinct is to migrate the easy things first for an early win. That gets the sequence backwards. The parts of a commerce platform that carry migration risk are the ones with the most integration surface — pricing rules, tax, availability, the ERP handshake — and they are exactly the parts you want to discover problems in while you still have budget and political capital.

A sequence that has held up across several builds:

1. Catalog and search first. Read-heavy, low blast radius, and it forces you to solve product data import and the PIM relationship immediately.
2. Content and landing pages next. Marketing gets visible value early, which buys patience for the quieter phases.
3. Cart and pricing after that. This is where the real business rules live, and where the legacy system's undocumented behaviour surfaces.
4. Checkout and payment last. Highest risk, most regulated, and by this point you understand the domain well enough to do it once.

Accounts and order history sit awkwardly across the whole sequence, because customers expect continuity. Plan for a period where both systems read from one identity source — usually the legacy one — rather than trying to migrate identity in the same slice as anything else.

The dual-write period is the hard part

For any slice touching writes, there is a window where both systems need a consistent view of the same data. Teams reach for dual-write and then discover that dual-write without an ordering guarantee is just two systems disagreeing at speed.

Publish domain events to a log — Kafka is the usual answer, and it is the right one — and let both systems consume from it. The legacy application gets a small outbound adapter, the new platform gets a consumer, and the log becomes the arbiter of what happened and in what order. This is more work upfront than a synchronous double-write, and it is the difference between a migration you can reason about and one you can only apologise for.

The question to ask about any dual-write design: when the two systems disagree, which one is wrong, and how do you find out before a customer does?

What actually goes wrong

Not the things in the risk register. In practice:

• Redirects. Nobody budgets for them, and a botched URL map costs more organic traffic than the replatform gains in conversion. Build the redirect map from the server logs, not from the sitemap — the sitemap does not know about the ten-year-old campaign URLs still earning links.
• Search relevance. The new search is objectively better and converts worse for six weeks, because merchandisers had years of tuning baked into the old one. Budget for re-tuning as a project, not as a task.
• Reporting. Finance has a spreadsheet that reads from a database view somebody built in 2017. It will be discovered two days before cutover.

None of these are engineering problems, which is exactly why they get missed by engineering-led migration plans.

When a big-bang cutover is right

Incremental is not always correct. If the storefront is small, the integration surface is thin, and the legacy system genuinely cannot be fronted by a proxy — some hosted platforms make this impossible — then the proxy layer is real work that buys you nothing you can't get from a well-rehearsed weekend cutover.

The honest test: if the incremental path costs more than about a fifth of the total migration budget in pure plumbing, and the rollback story for a big-bang is credible, take the big-bang. Rehearse it three times against production data first.

Here is what is really inside it, and roughly where a platform like Spryker stops helping and your build begins.

"Payment" mostly means credit

In B2C, payment is authorisation: is this card good for €80, yes or no, in two seconds. In B2B, the dominant payment method is on account — the order ships now and the invoice is due in thirty days — which means the question is not "is the card good" but "is this customer good for another €40,000 on top of what they already owe". That is a credit decision, and the data to make it lives in the ERP: open items, credit limit, payment history, blocks.

So the checkout has a synchronous dependency on the credit check, and you need three answers designed before anyone writes code:

1. Where is the check made? Asking the ERP live is accurate and couples your checkout availability to the ERP's uptime. Replicating exposure data into the shop is fast and can be minutes stale — which matters exactly when a customer is placing orders rapidly, which is exactly when credit matters.
2. What happens on "no"? Hard-blocking the order loses revenue over data staleness. The pattern that survives contact with sales teams: accept the order into a review state, tell the customer honestly, and give the credit team a queue. A blocked checkout is a phone call to sales anyway; better to own it in the system.
3. What happens on "unknown"? The ERP will be unreachable during checkout at some point. Failing open or failing closed is a finance-department decision. Get it in writing; you are choosing between lost orders and bad debt.

Spryker gives you the plumbing here — a payment method plugin architecture and a state machine per payment method — and none of the policy. The state machine you configure is the credit policy. Treat that XML with the reverence you would give pricing code.

The order is a committee

A B2C order has one human. A B2B order routinely has three: the requester who fills the cart, the approver who owns the budget, and purchasing who owns the supplier relationship. Spryker's company account model — business units, roles, permissions, approval flows — covers the healthy 80%: spend thresholds per role, approve or reject with a comment, notifications.

The remaining 20% is where the workshops earn their keep, because approval rules encode the org chart, and org charts are weird. Approval by cost centre rather than amount. Deputies for approvers on holiday. The rule that chemicals need a safety officer's sign-off regardless of price. You will not configure that; you will build it. The trick is to find out which of those rules are real requirements and which are how the old fax workflow happened to work. Asking "what happens today when this rule is violated?" kills about half of them.

Punchout, quotes, and the other doors into checkout

A serious B2B storefront has more entrances than the cart button:

• Punchout (OCI/cXML). Your biggest customers may never see your checkout at all — their procurement system opens your catalog, the filled cart is returned to their system, and the order arrives later as an EDI or API message. Checkout, payment and approval all happen on their side. If the target segment includes enterprises with SAP Ariba or Coupa, punchout is not an add-on, it reshapes what "checkout" even means for your best accounts.
• Quotes. Above a certain order value, the cart is an opening bid. Request-for-quote flows — cart becomes a quote, sales adjusts prices, the customer converts it back into an order — blur the line between commerce platform and CRM. Decide early which system owns a negotiated price and how long it is honoured.
• Order templates and replenishment. The weekly re-order of two hundred line items is the actual daily life of B2B buying. A checkout optimised for the first-time visitor and unusable for the two-hundred-line repeat order has optimised the wrong funnel.

None of this is exotic. It is the ordinary contents of the phrase "B2B checkout", visible only if you unfold it before the estimate instead of after. The projects that go well are the ones where the credit policy, the approval matrix and the punchout question were on a whiteboard in week two — while the projects that go badly discovered them in UAT, one surprised stakeholder at a time.

None of this shows up in an engineering estimate, because it is not engineering work. It shows up in the engineering timeline, because the storefront cannot be finished — not styled, not tuned, not tested — against data that does not exist yet.

Why the demo lies

Every platform demo runs on curated data: complete attributes, pretty images, clean categories. Real catalogs have products with three parents, attributes whose meaning changed in 2019 without anyone renaming them, and a "colour" field containing values like blue/darkblue (new). The storefront features that sell the project — faceted search, comparison tables, rich variant switchers — are exactly the features that quietly degrade into empty boxes when the attributes behind them are 60% filled.

That 60% is the number to chase down early. Pick the twenty attributes your storefront design actually depends on, measure fill rates across the real catalog on week one, and put the number in the steering meeting. It reframes the conversation from "when will dev be done" to "when will the data be launchable", which is the true question.

What a PIM actually buys you

Teams reach for a PIM — Akeneo, in most of the projects I see — expecting it to solve data quality. It does not. What it solves is data workflow, which is upstream of quality:

• One place where enrichment happens, instead of the ERP for logistics fields, a spreadsheet for marketing copy, and the shop's admin for whatever was forgotten. The shop stops being an editing surface, which is the single biggest simplification available.
• Completeness as a first-class number. Akeneo's completeness model — required attributes per channel and locale — turns "is the catalog ready" from an opinion into a dashboard. Product families below threshold do not export.
• Translations as a process, with locales that inherit and fall back, instead of column pairs in a spreadsheet named FINAL_v3_reviewed.

What it cannot buy you is the enrichment itself. Somebody still writes the copy, sources the images, and decides whether blue/darkblue (new) is one value or two. A PIM makes that work visible and assignable. It does not make it happen. Budget the people, not just the licence.

The import pipeline is production code

The connector between the PIM and Spryker gets built as a throwaway script surprisingly often, considering it runs every night for the life of the platform. It deserves the same engineering as checkout:

1. Validate at the boundary, reject loudly. A product with a broken category reference should land in an error report with a reason, not silently vanish from the shop. Silent drops get discovered by the sales team, weeks later, one SKU at a time.
2. Import deltas, but rehearse the full load. The nightly delta keeps the day-to-day cheap. The full re-import is your disaster recovery and your go-live path, and if it has not run in three months it does not work.
3. Make throughput a tested number. Spryker's data import and Publish & Sync machinery is batch-friendly, but a naive per-product loop with an event storm behind it will turn twelve thousand products into a nine-hour night. You want to know that in week four, not on cutover weekend.

Sequence the work honestly

The planning mistake is treating data as a workstream that runs "in parallel" with the build, which in practice means nobody looks at it until the storefront needs it. The sequence that works inverts the usual order: model the catalog and stand up the real import in the first weeks, against the ugliest data you have, and let the storefront be built on top of real products from day one.

It feels slower, because the first sprint produces importers instead of pages. It is faster, because the alternative is discovering the catalog's actual shape during the final integration phase — which is the most expensive possible moment — and because every screenshot after week three shows the client their own products, not lorem ipsum in a hoodie.

The launch date is not set by the last feature merged. It is set by the day the data is fit to sell with. Treat that as the deadline and staff it like one.

Decide who owns each field, in writing

Every integration problem I have debugged at two in the morning reduces to the same root cause: two systems both believed they owned a piece of data. Prices maintained in the ERP and "temporarily" overridden in the shop. Stock corrected in the warehouse system and cached optimistically in the storefront. A customer record edited on both sides of the fence in the same afternoon.

The fix is boring and organisational, not technical. Before any mapping work starts, produce a table: every entity, every field, one owning system, one direction of flow. Products flow from the ERP (or the PIM) to the shop, never back. Orders flow from the shop to the ERP, never back — the ERP sends order status, which is a different object. Anyone who wants an exception to the table has to argue for it in a meeting, which is exactly as hard as it should be.

Pricing is where B2B integrations earn their reputation

B2C pricing replication is a nightly file and a sanity check. B2B pricing against SAP means condition records — customer-specific prices, quantity scales, date-bounded agreements, sometimes thousands of combinations per account. You have two honest options:

1. Replicate. Flatten the condition logic into Spryker's price dimensions and import the result. Fast storefront, and a re-implementation of SAP pricing that will drift from the original the first time someone adds a condition type nobody told you about.
2. Ask SAP at cart time. Always correct, and now your cart's response time includes a round trip to a system that was sized for batch jobs, with a failure mode in the middle of checkout.

The pattern that has held up: replicate list and contract prices for browsing, and make one synchronous pricing call when the cart actually matters — on cart review, not on every quantity change. Cache the response against the cart hash. And decide now what the storefront shows when that call times out, because it will, and "spinner forever" is a decision too, just a bad one.

The order export is a distributed system, own up to it

Posting an order into an ERP is not a REST call, it is a small distributed systems problem wearing a business suit. The ERP will be down for maintenance windows the project plan never heard of. It will accept an order and time out on the acknowledgement. It will reject an IDoc for a reason that is true but useless, like a sales area mismatch on a customer who ordered fine last week.

Minimum viable honesty here is an outbox: the shop commits the order and an export job in one transaction, a worker retries with backoff, and every export carries an idempotency key so a retry after a lost acknowledgement does not book the revenue twice. I have seen the double-booked version. Finance finds it at month end, and they do not describe it as an engineering detail.

The test for any order export design: kill the connection after the ERP has accepted the order but before your system hears about it. If the answer involves a human comparing spreadsheets, the design is not done.

The middleware question

Somebody will propose an iPaaS — Mulesoft, Boomi, SAP's own integration suite — and somebody else will propose "just build it in the shop". Both are wrong as defaults. The iPaaS earns its licence when there are many systems and the mappings are genuinely configuration; it becomes an expensive place to hide business logic when there is really only one integration that matters. Direct integration is fine for one system and gets quadratically worse as systems join.

The question that actually decides it: who will change the mapping in three years, and what tools do they know? An integration layer nobody on the retained team can operate is technical debt with a subscription fee.

Whichever way it goes, put contract tests on the boundary. A fixture file of real (anonymised) IDocs and API payloads, replayed in CI against your mapping code. When the ERP team upgrades and a segment quietly changes meaning, you want a red build, not a warehouse full of wrong picks.

The storefront demo is what sells the project. The field-ownership table, the outbox, and the fixture suite are what let you sleep after it launches.