Magento Consultant Due-Diligence Checklist

1. Fix the decision and its owner

Due diligence fails when a consultant receives a broad request such as “review our Magento setup” and nobody owns the resulting choice. Write the decision before collecting evidence.

1. Name one accountable buyer. Record who owns the decision, who can approve spend, who gives technical sign-off, and who accepts business risk. Advice does not transfer accountability to the consultant.
2. Write the decision question. Examples include whether to acquire a commerce asset, retain Magento, move to Adobe Commerce, choose another platform, or accept a supplier proposal.
3. Define the decision boundary. State the brands, countries, storefronts, legal entities, channels, systems, data, and contract period inside the review.
4. Set non-negotiable constraints. Record regulatory duties, launch dates, contractual limits, operating capacity, approved risk, and business capabilities that cannot be lost.
5. Separate facts from judgments. Every material statement should be labelled as observed evidence, a buyer assumption, a consultant assumption, or a recommendation.
6. Keep a decision log. Record the option chosen, options rejected, evidence used, unresolved questions, dissent, approval date, and facts that would reopen the decision.

2. Test an acquisition before valuing the technology

For an acquisition, confirm what the buyer will actually own and operate. Do not infer ownership from access to a storefront or repository.

Acquisition red flags that need written resolution

• The seller cannot show a complete list of custom code, extensions, licences, and recurring technology contracts.
• Core accounts, domains, repositories, cloud resources, or signing keys are held in a founder's, employee's, or supplier's name.
• Architecture diagrams and data-flow records do not match the working system.
• Critical capability depends on one undocumented customisation or one person who is not part of the transaction.
• Source ownership, contractor assignments, licence transfer, or third-party data rights are unclear.
• The seller reports revenue or operational performance without a traceable definition, period, source system, and reconciliation method.
• The current platform version or material extension has a known support deadline, but the forecast excludes the required work.
• The consultant cannot state which acquisition facts it verified and which were supplied without verification.

Decision rule: price uncertainty explicitly. A missing contract, unclear right, or undocumented dependency is not a zero-cost assumption. It needs a condition, cost range, holdback, warranty, or a reason to stop the transaction.

3. Require architecture evidence, not a diagram alone

An architecture recommendation must connect business capabilities to systems, data, interfaces, operational ownership, and measurable constraints. A presentation diagram is only an index to the underlying evidence.

1. Current-state system map. Show Magento or Adobe Commerce, frontend, content, search, payments, tax, ERP, PIM, CRM, identity, marketplaces, analytics, fulfilment, and reporting. Name the owner and purpose of each system.
2. Capability map. Link required customer and operator capabilities to the system that provides them. Mark duplication, manual work, known limits, and capabilities with no clear owner.
3. Data ownership map. For customers, products, prices, inventory, orders, refunds, content, and consent, identify the authoritative source, consumers, update direction, frequency, validation, retention, and reconciliation rule.
4. Integration register. For every interface, record protocol, trigger, payload owner, authentication, volume, service expectation, error handling, retry rule, monitoring, support owner, and business effect of failure.
5. Quality evidence. Request repository history, automated test results, dependency reports, performance measurements, accessibility findings, release data, and operational metrics. State the measurement date and environment.
6. Constraint record. Document licence limits, data residency, security controls, peak demand, latency, content workflow, checkout rules, local markets, internal skills, and approved operational complexity.
7. Target-state differences. Every proposed change should identify the current problem, expected benefit, systems affected, new dependency, new owner, migration need, validation method, and reversal difficulty.

4. Compare platform options on one requirements set

Platform selection should not start with vendor demos. Build one requirements set and apply it to every viable option, including the option to improve the current estate.

Options the consultant should consider

Ask the consultant to justify the shortlist before scoring it. Depending on the buyer's requirements, the set may include improving the current Magento estate, upgrading within Adobe Commerce, selecting another managed commerce platform, or adopting a more composable architecture. Do not force an option into the final matrix when it fails a documented non-negotiable requirement. Record the reason for exclusion.

1. Use the same definitions. Capabilities, demand, countries, contract length, service level, cost period, and risk scale must mean the same thing for every option.
2. Expose weighting. The buyer approves criteria and weights before a preferred vendor is known. Run a sensitivity check to show whether a small weight change reverses the result.
3. Verify decisive claims. A vendor statement, consultant experience, prototype result, contract term, and measured production result are different evidence types. Label them.
4. Show trade-offs. State what the buyer gains, loses, must replace, and must newly operate under each option.
5. Preserve the rejected paths. Record why they lost and which changed facts would make them viable later.

Use the separate platform decision matrix to make criteria, weights, proof, and reversibility visible.

5. Audit TCO over a defined period

Total cost of ownership is a model, not a quoted project total. Require a defined period, such as three or five years, and make the start date, currency, tax treatment, inflation, growth, usage, confidence, and contingency visible. Compare options over the same period.

TCO assumption checks

• Every material input has a source, owner, date, unit, and confidence level.
• Demand drivers such as storefronts, orders, catalog size, traffic, markets, users, storage, and API volume are explicit.
• One-time, recurring, usage-based, inflation-linked, and contingent costs are separated.
• Benefits are not subtracted from cost unless the model states the baseline, owner, measurement method, timing, and confidence.
• Best, expected, and adverse cases show which assumptions create the difference.
• The model states whether delay, parallel systems, contract overlap, data clean-up, and internal buyer effort are included.
• Costs outside the consultant's proposal are still included in the buyer's model.

Decision rule: reject an option comparison when its cost periods, scope, demand assumptions, or risk treatment differ. Normalise them before drawing a conclusion.

6. Review the proposal as a control document

A proposal should make obligations testable. Marketing language does not replace a scope baseline, evidence rules, or buyer rights.

Demand portable outputs

The buyer should own or hold sufficient continuing rights to use the engagement output with another adviser or supplier. Require editable and readable formats, not only presentation slides or access to a supplier portal.

• Approved brief, stakeholder record, requirements register, and traceability matrix.
• Current-state findings, evidence index, system map, data-flow map, integration register, and risk register.
• Option shortlist, evaluation criteria, weights, raw evidence, scoring logic, sensitivity test, and decision record.
• TCO model with formulas, source inputs, assumptions, scenarios, and version history.
• Target architecture, transition sequence, dependencies, open decisions, validation plan, and ownership model.
• Meeting decisions, unresolved questions, dissent, conflict disclosures, and final recommendation.

7. Record conflicts and implementation incentives

Do not describe any consultant as independent without defining the relevant commercial structure. Useful advice can come from different business models, but the buyer needs to see and control the incentives.

1. Platform relationships. Ask for current partnerships, accreditation programmes, co-marketing, sales targets, rebates, licence resale, marketplace income, and non-public vendor access relevant to the options.
2. Referral arrangements. Ask whether the consultant can receive money, credit, reciprocal work, or another benefit for referring a platform, supplier, extension, hosting firm, or specialist.
3. Implementation interest. Confirm whether the consultant or a connected delivery business may bid for work created by the recommendation.
4. Existing relationships. Record prior work for the buyer, seller, platform vendors, current suppliers, bidders, and investors that could shape access or judgment.
5. Decision separation. Approve the advisory output before awarding implementation. Keep the right to run a separate competition or appoint another supplier.
6. Change disclosure. Require prompt written disclosure when a new commercial relationship, referral, bidder, or delivery opportunity appears during the engagement.

8. Apply a final approval gate

Do not approve the recommendation until the accountable buyer can answer yes to the following questions.

1. Decision: Is the exact decision, boundary, owner, approver, deadline, and success condition written down?
2. Acquisition: Are ownership, contracts, rights, data duties, technical condition, dependencies, and unresolved liabilities visible?
3. Architecture: Can important claims be traced to current evidence, named owners, measurements, and dates?
4. Options: Were viable paths tested against the same requirements, assumptions, evidence standards, and cost period?
5. TCO: Can the buyer inspect formulas, source inputs, uncertainty, adverse cases, internal costs, and exit costs?
6. Proposal: Are scope, exclusions, dependencies, assumptions, change control, acceptance, exit, and correction duties enforceable?
7. Portability: Can another qualified party review and continue the work using buyer-controlled outputs?
8. Conflicts: Are platform, referral, resale, relationship, and implementation incentives disclosed and controlled?
9. Uncertainty: Does the decision record show what is unknown, who owns it, its possible effect, and what would reverse the recommendation?

Stop condition: pause approval when a missing fact could change the platform choice, acquisition value, architecture, total cost, contractual duty, or ability to exit. Assign an owner and resolution date instead of converting the gap into an optimistic assumption.

Continue the decision process

Start with the main Magento consultant comparison. Then use the second-opinion brief to define the question, the decision matrix to compare options, and the independence method to inspect evidence and conflict profiles. Read about this publication and its editorial policy for scope and correction standards.