Before deciding to replace an older online store, establish which code is live, what the business depends on and whether recovery has been demonstrated. A useful first audit produces a system map, an evidence-backed risk register and an ordered plan for the next decisions.
A storefront can load correctly while its maintenance position is unclear. Scheduled integrations may be failing, local source may lag behind production, and a folder labelled “backup” may cover only part of the system. Discovery turns those unknowns into questions the owner can answer before authorizing changes.
1. Identify the live system and its owners
Record the hosting account, domains, application runtime, CMS, database and external services. For each component, identify who controls access and where the current configuration is maintained.
Keep observations separate from conclusions. A version string is evidence to investigate against the vendor's support policy. It is not, by itself, proof that an incident has occurred. An unfamiliar account is an ownership question until its role is established.
The audit should stay inside an agreed read-only boundary. Credentials, customer records, private order details and intrusive scanning do not belong in an unrestricted first pass.
2. Reconcile source with the published version
Find the maintained source repository and identify the deployed revision or artifact. Do not assume the newest local folder is the source of production.
Compare the relevant compiled application, configuration and assets using the strongest evidence the hosting setup provides. Record what matched and what was outside the comparison. A backend bundle match does not prove that published images, HTML or database migrations also match.
If production changes during the review, bind the evidence to its version and timestamp. Reconcile the new baseline before preparing a patch. This protects the owner from a repair that quietly removes a newer feature.
3. Map the integrations that carry revenue
List payment processing, stock and price imports, delivery calculation, order notifications, accounting exports and administrator workflows. For each connection, record its input, output, schedule, owner and observable failure signal.
Start with the business consequence. A broken product feed and a broken paid-order notification need different priorities and acceptance checks. “The integration is configured” is weaker evidence than a dated receipt showing that the expected record reached the expected system.
Avoid treating a successful HTTP response as proof of an external result. The receiving application or provider record may be needed to confirm what happened.
4. Inspect scheduled work
Compare configured jobs with the scripts, services or handlers they actually invoke. Look for missing targets, obsolete paths, repeated failures and jobs whose current purpose is unknown.
Record dependencies before proposing to disable a schedule. One handler may both send reminders and update a delivery exchange rate. A blanket shutdown can remove useful work along with the risky path.
Separate the finding from the repair. Discovery documents the condition and its business effect. Changing a production schedule requires its own defined scope and verification.
5. Establish what a backup can recover
List the components needed to restore the store: source and release artifacts, database, uploaded media, required configuration and a secure recovery path for secrets. Record the target, retention and latest successful producer receipt for each class.
An existing bucket or archive name does not prove coverage or integrity. An empty location does not prove that no other backup exists. State both limits clearly.
The stronger test is a restore into an isolated environment with an agreed dataset, followed by application checks. That is separate from a read-only inventory and needs an explicit recovery scope. Until it has been performed, label restore capability as unverified.
6. Follow checkout and notifications as separate workflows
Inspect how the application creates an order, requests payment, receives the provider event and notifies the team and buyer. Check how it handles duplicate events and uncertain outcomes.
A browser return page is not payment confirmation. An order marked paid is not proof that its notification was delivered. Keep those states and their evidence distinct.
Use synthetic inputs and test doubles for local checks. Live transactions, refunds and real messages need their own authorization and provider-side acceptance evidence. A first discovery pass should not create them implicitly.
7. Preserve search visibility during modernization
Inventory important product and category addresses, canonical URLs, redirects, robots directives, sitemaps and the current analytics setup. Review the pages the business depends on before proposing a new route structure.
Record whether an old address redirects, returns an error or serves a different page. Do not manufacture performance conclusions without search or analytics data. If access is unavailable, state which measurements are missing and make collecting a baseline part of the next phase.
An application rewrite and a search migration are related decisions. They deserve a shared URL map and acceptance plan, rather than a cleanup performed after launch.
8. Separate immediate findings from staged work
The owner needs an ordered decision list, not a long collection of equally urgent warnings. For each item, record the observed condition, source, likely business consequence, confidence and proposed next action.
A practical report distinguishes:
- A finding that can be verified from the agreed public or read-only evidence.
- A change that can be prepared locally and reviewed.
- Work that needs staging, more data or an external-system check.
- A production operation requiring a separate authorization and rollback plan.
This does not make a repair safe merely because it is small. It makes the assumptions visible before the owner accepts the scope.
What the owner should receive
The first audit should leave a system map, an evidence register, a risk list ranked by business impact and a sequence of next steps. Unknowns should remain visible: an untested restore, an unresolved integration owner or an incomplete source comparison is useful information.
Hlinor's published first legacy-store case and MODX case study illustrate how the findings can differ even when both storefronts appear operational. They are anonymized examples, not a prediction about another store.
Start with the question you need answered
If you only need an initial view from public signals, Legacy Store Risk Triage is the smaller starting point. For source, integration and recovery questions, Kintsugi Kode provides a scoped legacy-system audit after intake.
Send the system type, the business decision in front of you and the materials you can safely share. Do not include passwords, API keys or customer data in the first message. Submit a case.