First: stabilize
Remove public artifacts, stop broken automation, confirm backups and document the current system before making structural changes.
Kintsugi Kode Case Study 01
A revenue-generating store looked healthy. The audit found risks the owner could not see.
The storefront loaded. Customers could browse. Revenue was still coming in. But the system had become a black box: old runtime, undocumented automation, exposed internal artifacts and no clear migration path.
Anonymized case study. Client name, domain, geography, credentials and hosting account are not disclosed.
The situation
The client was running a specialized e-commerce store on a legacy CMS stack. The business depended on it: product pages, catalog navigation, order flow, customer communication and integrations all passed through the same system.
From the outside, there was no obvious emergency. The site looked alive, pages loaded, and customers could interact with the catalog. The real problem was operational uncertainty: no current system map, no staging environment, and integrations originally built by someone no longer involved.
The owner did not need a blind rewrite. They needed to know what was safe, what was fragile, what was already broken, and what should happen first.
Why the owner asked for discovery
- Every small change felt risky because nobody had a full picture of the system.
- Legacy components had accumulated over several years.
- Automation and integration status was unclear.
- The owner needed a practical plan before investing in repairs or migration.
- The first rule was clear: read-only discovery before touching production.
What we found
The audit connected technical symptoms to business risk. The point was not to list scary findings. The point was to show what could interrupt revenue, block modernization or make every future fix more expensive.
Critical
Unsupported web runtime.
The store was running on an end-of-life PHP branch. The site still worked, but the runtime no longer received security patches, making future maintenance and incident response riskier.
The store was running on an end-of-life PHP branch. The site still worked, but the runtime no longer received security patches, making future maintenance and incident response riskier.
Critical
Internal server artifacts in public web access.
A server log archive was reachable through a direct URL. This kind of file can expose paths, errors, request patterns and operational details that should never be public.
A server log archive was reachable through a direct URL. This kind of file can expose paths, errors, request patterns and operational details that should never be public.
Critical
Silent automation failures.
Scheduled tasks were still firing but called scripts that no longer existed. That meant an integration had silently stopped working at an unknown point in the past.
Scheduled tasks were still firing but called scripts that no longer existed. That meant an integration had silently stopped working at an unknown point in the past.
High
CMS files left in public directories.
Old CMS source or installation artifacts were left in web-accessible paths, unnecessarily exposing platform structure and version clues.
Old CMS source or installation artifacts were left in web-accessible paths, unnecessarily exposing platform structure and version clues.
High
Long-lived dependency layer.
Dozens of components had been installed over several years. Some were core to payments, catalog behavior, search, captcha and operational flows.
Dozens of components had been installed over several years. Some were core to payments, catalog behavior, search, captcha and operational flows.
High
Checkout friction was discovered too late in the customer journey.
Payment limitations were visible only after the customer had already moved deep into the purchase flow, creating avoidable conversion loss.
Payment limitations were visible only after the customer had already moved deep into the purchase flow, creating avoidable conversion loss.
What changed after approval
The discovery phase did not modify production. After review, the owner approved a focused set of low-risk quick wins.
- Public internal artifacts were removed from direct web access.
- Obsolete CMS source artifacts were removed from the public path.
- Broken scheduled tasks were documented and disabled instead of silently failing.
- The owner received a clear explanation of what had been changed and what remained untouched.
What the owner received
- A system map showing the main CMS, catalog, payment, automation and hosting layers.
- A risk register ranked by business impact, not just technical severity.
- A technical debt review covering runtime, dependencies, integrations and documentation gaps.
- A quick wins list separating safe cleanup from changes requiring staging.
- A 30/60/90-day modernization roadmap.
The real value was not the cleanup. It was the order of operations.
Legacy systems become dangerous when every problem looks equally urgent. The audit separated immediate risk, staged technical work and long-term modernization.
Second: test through staging
Update critical components in a controlled environment. Payment, cart, search and captcha-related modules should not be upgraded blindly on production.
Third: modernize deliberately
Move runtime and dependencies to supported versions, restore missing business flows and decide which parts should be preserved, refactored or migrated.
Next case
Case Study 02: a strong MODX store with access, artifact and catalog debt.
The second case goes deeper into a mature e-commerce system: public admin utility, public CMS artifacts, 89 exposed package archives, shared administrator access, runtime mismatch and catalog dictionary drift.
Before you rewrite a system, understand it.
Kintsugi Kode turns old websites, CRMs and backend systems into a map, a risk register and a practical action plan.