Planning an enterprise eCommerce implementation is notoriously difficult. There’s no single best way to approach it. Every organization has a different mix of legacy systems, required features, customers, and staff, not to mention the internal politics that can shift requirements like the moon shifts the tides.

But there are some commonalities. Almost every enterprise site we undertake begins with a massive feature list and gap analysis, and organizations often try to understand the scale and complexity of their implementation by classifying features. 

They put them in buckets like:

• Out of the box
• Requires configuration
• Requires custom code
• Completely custom development

Each one is a different level of effort, and theoretically, these buckets will help with estimation and planning.

The problem? Terms used to describe features are often fuzzy and unclear.

Take “invoicing” as an example. Invoicing can mean 18 different things to 13 different people. It's not a single feature—it's a category of features. There might be an “invoicing” module in the platform you are evaluating, but does that actually satisfy the requirement? It depends on what "invoicing" actually means to your organization. 

Determining a true level of effort requires a lot of planning and conversations on its own. Trying to architect every single detail up front like this can lead to madness. You get too far ahead of yourself, and suddenly, all of the time you spent detailing and architecting features that won’t work or you don’t need anymore is sucked down a big, black hole.

Follow the customer journey

Rather than attempting to architect every detail up front, we organize our planning around the customer journey. This provides a natural framework for both discussion and development.

Acquisition

How do new customers find you? They probably don't type in your URL directly. They search, and you appear as a result. This leads to questions about marketing and product content, which leads to content modeling, the editorial experience, and how to attract and engage new visitors.

Engagement

Once you've acquired visitors, how do you hold their attention? This includes product categories, search interfaces, conversational search, quizzes, wishlists, and other engagement tools that guide visitors toward conversion.

Conversion and fulfillment

The customer journey then flows through Add to Cart processes, cart management, checkout flows, and payment processing. After the order is placed, what happens next and when? Who is responsible? What systems are notified?

This sequential approach makes sense because you can't have an Add to Cart form until you have a product definition. You can't have a checkout flow until you have a cart. You can't have a meaningful order history page until someone has placed an order.

Understand the organizational model

Most enterprise implementations we handle are B2B, which adds another layer of complexity. You need to understand:

• What is the customer organization model?
• How are data objects created by the platform managed internally by business customers?
• Does a procurement manager need to sign off on purchase orders before completion?
• Are licenses shared between organization members?
• Who can see the order history?
• Who provisions orders and who fulfills them?

These B2B-specific requirements significantly impact how you architect user management, permissions, and workflows. All of these look far different for a platform that is only or primarily B2C.

The definition phase

Once you’ve mapped out the main contours and features of the landscape, you can start going into more detail and digging under the surface.

During the definition phase, you need enough of a skeleton to feel confident in your budget proposal, but you're not trying to reconstruct the entire dinosaur. Think of it like hanging bones in a museum gallery. You can see the shape and identify where you'll need to zoom in for more detail.

Here are a few things to define.

Feature areas and epics

Understand broadly what the website will do for your organization, with enough sub-detail to organize your work. For invoicing, this might include proforma invoices requested via RFQ forms, converting proforma invoices to sales receipts, user dashboards for viewing and paying open invoices, and credit memos for refunds.

Systems of record

Determine where data lives. Some data will be owned by your ERP, some by your warehouse management system, some by your product information management system, and some in the eCommerce platform itself. Understanding these boundaries up front is critical, because they represent the lines of systems integration required to bring your project to life.

Data synchronization strategies

For each data type, decide whether you're replicating data from third-party systems inside your eCommerce platform, caching it temporarily, or always requesting it in real-time. Each strategy has different cost and performance implications.

Non-functional requirements

Document compliance, legal, regulatory, and accounting requirements. These might include PCI DSS compliance, export limitations, regional product availability restrictions, or multilingual and multi-currency requirements. These requirements affect how everything gets implemented. For example, Worthington Biochemical can’t ship certain products to certain countries due to export limitations and doesn’t sell directly to others to honor regional distribution agreements.

Avoid maximum specificity

More projects suffer from overly protracted discovery and architecture engagements than benefit from them. Why? It sounds counterintuitive. Shouldn’t more planning lead to better results? 

Because attempting to architect every edge case in advance wastes money at the start of major projects. Why start obsessing over window curtains before the foundation has been laid?

When starting a complex project, you have many hypotheses about how things will work. But when you actually sit down to build, you often realize your approach won't work as planned and must change course. If you've already architected the entire application based on that initial data model, all of that becomes irrelevant when you need to pivot.

We recently worked on a stock implementation that was initially supposed to split order items when inventory came from batches with different unit costs. The architecture seemed sound. Allocate six items against inventory lots, split the order item into two (quantity 2 and quantity 4), and assign different unit costs to each.

However, our lead developer pointed out that orders already packed into shipments reference specific order items. Splitting order items would require updating shipments simultaneously, adding significant complexity. 

Based on the budget and timeline, we chose to average the unit cost instead. It was much simpler and was close enough for the customer's actual needs.

Just-in-Time architecture

Instead of front-loading all architectural decisions, we defer detailed architecture discussions to the beginning of the development sprint that addresses each feature set. This approach:

• Allows learning from earlier sprints to inform later decisions
• Reduces wasted effort on architecture that may need revision
• Focuses the budget on delivering actual capabilities rather than documentation
• Maintains flexibility to adapt as requirements evolve

Only bring the data architecture that you need

A skilled eCommerce developer wants to bring only what's necessary into your platform. But sometimes he won’t know what's necessary until he’s neck deep into the system and understands the platform.

Consider a client with over one million SKUs. If this company needs to batch update 100,000 SKUs at midnight several times per year, you'll hit throughput limits. Full entity updates in Drupal can be costly. You can only save so many entities per hour without degrading website performance.

So we minimize the data surface area. Rather than importing all product data into the platform's product entity, we only store the title, SKU, and base price. The other 100+ data points? They read and write directly to a separately managed search index.

This approach enables a highly available product catalog with a million SKUs while achieving peak performance by lazy loading extra product data only when users visit individual product pages.

Workflow customization

For managing orders, shipments, payments, invoices, licenses, and subscriptions, we use workflows designed to be customized and tailored, similar to how project management tools let you customize issue workflows.

A common best practice is “Poka-yoke,” a Japanese term for mistake-proofing a system. It comes from Toyota.

When fulfilling an order, don't just have a confirmation form that asks, "Are you sure?" Instead, if you require tracking codes for every shipment, that transition form should force you to input a tracking code. This eliminates the need for customer service representatives to manually email tracking information later.

Plan what happens when transitions occur—sending data to the ERP, capturing requests to the payment gateway, and shipping labels to the warehouse management system. Chart this out to ensure the correct transitions happen in the correct order, making it impossible for staff to complete orders without capturing payments or to finalize shipments without proper tracking. Building this out might take longer in the short term, but it will save your people time and money in the long run.

Key workflow design principles

• States are descriptive, transitions are actions. Many people create weird mismatches, like a transition called "awaiting shipping." Instead, the action should be "validate this order," which puts it into the state of "awaiting shipment."
• Automate what can be automated. Use appropriate messaging mechanisms like fault-tolerant, asynchronous message queues, so you're not hanging the entire website because an API request is taking too long.
• Integrate thoughtfully. Ensure you're automating through the right channels to maintain system performance while meeting business requirements.

Data migration and the point of diminishing returns

Data migration from third-party systems is usually a part of every project, and a challenging one. Different data models, data types, and architectures can cause delays and hiccups. However, with enough time and testing, most migration problems can be solved. At the end of the day, you are moving source data to the destination architecture, and you can transform that data so it appropriately maps to the destination.

But what is essential to retain? Do you really need everything? And if you do, does the data need to remain perfectly formatted in certain ways? What do your customers actually need? What does your staff actually use? What do your internal systems actually require?

Data migration can balloon a budget, especially if you get precious with every jot and tittle. And for what? Make sure there’s a clear business case. You don’t want to migrate massive amounts of historical data that won't benefit anyone.

If a third party is your system of truth, keep what's central and potentially change how you relay order histories. You could fetch them in real time from your ERP when customers visit the dashboard rather than maintaining duplicate records.

Some strategies for efficient migration

• Flatten the data. If price matching is sufficient, use a single generic discount adjustment rather than trying to perfectly model every promotion, price list, or coupon from your old system.
• Truncate appropriately. Do you really need log messages from orders 10 years ago? Create simple, clear rules. For example: Migrate carts from the last 30 days only, and everything older gets deleted.
• Summarize where possible. If your ERP is the source of truth for transactions, you don't need to migrate one-for-one every transaction from your previous system. The final tally should be sufficient.
• Prioritize critical data. Focus on user accounts (perhaps including passwords for seamless authentication), order histories (but maybe not full payment history), and current inventory (but not historical stock movements).

Focus on what differentiates your business

Very few organizations are coming online for the first time. They already have a platform. They already have systems in place. They have already spent a lot of money. And nobody wants to spend money on something they’ve already spent money on, especially if they thought it would last several more years. 

Maybe this is you. If so, you want to know your ROI. What new capabilities are you bringing in? How will this make your customers happier, increase your customer base, or decrease your operational expenses? All fair questions.

The planning we’ve detailed above is designed to get through the remedial phase as fast as possible, so we can focus on higher-value features that differentiate your business from competitors. We want you to get to the point where you’re applying your budget to building new capabilities as quickly as possible.

• Avoid pointless definition exercises that get revamped halfway through the project
• Avoid migrating massive amounts of stale data that doesn’t benefit anyone
• Avoid trying to make your platform something it was never intended to be when better tools exist, for cheaper. For example, analytics or CRM functionality.

Some of these are table stakes for a functioning platform and business continuity. You want some kind of plan. You want to migrate relevant, historical data. But you don’t want to spend a huge percentage of your budget.

Not perfection, but efficiency in execution

The goal isn’t perfection in planning. You risk wasting a lot of money once you start testing the wheels out on the open road.

Aim for efficiency while delivering real business value.

We’ve refined this process over years of enterprise implementations. If you want to see how Drupal Commerce and Centarro can build your next eCommerce platform without compromise, contact our team.