An improvement to your warehouse operation can be a change to the WMS you have, a connected application or a replacement system. For the COO or operations director funding it, the decision starts with which work needs to change and which system should be responsible for it.

Keep the parts that run the operation well. Use supported configuration where it meets the requirement. An extension makes sense when it can take responsibility for a defined piece of work and return a clear result. Consider wider replacement when keeping the existing WMS means duplicating its core decisions elsewhere and continually reconciling the two.

Establish what the existing system can support

A warehouse management system connects stock information with the work of receiving, storing and dispatching goods. Its configuration may already support a different way of organising that work. For example, Microsoft’s warehouse management overview describes work templates, location directives, inventory statuses and returns processes. A particular requirement needs checking against your product and implementation.

Ask someone who knows the current system to show how it would support the process you want. If staff need a clearer returns queue, find out whether an existing view or workflow can provide it. A useful answer includes what the team will see, what they will do and how the resulting stock record changes.

Also establish why the current process fails. Incorrect product data, inconsistent use of stock statuses or an unclear responsibility can survive a software replacement. Fixing them may be enough to make the supported process work. If an important requirement still cannot be met, you have a more precise gap to scope.

A returns workbench can have a clear boundary

Consider this illustrative 3PL operation. Its WMS handles receiving, stock reservations and dispatch adequately, but the team manages returns assessment in a separate spreadsheet. A returned item needs a condition assessment and a next action under the client’s agreed policy. Some items await assessment; others need rework or a client decision.

A connected returns workbench could give staff that work in one place. The assessor opens the receipt, records the condition and follows the applicable next step. A team lead can see which returns are ready to work on and which are waiting for someone else. The operation can improve how it organises assessment without replacing the system that already manages ordinary stock movements.

That extension has a workable boundary if the WMS can record returned goods as unavailable, accept the assessment result against the original receipt and make the authorised stock change. The returns application owns the assessment work; the WMS remains responsible for stock availability and reservations. Your technical team needs to confirm those capabilities in the actual WMS.

Finishing the assessment and updating the WMS are separate events. If the update fails, the workbench should show that the result still needs sending. It must not quietly treat the item as available while the WMS records something different. Specify how staff resolve that gap and how repeated messages avoid repeating the stock change. These are requirements for the integration, not reasons to reject every extension.

This is the boundary to judge: a defined piece of operational work produces a result that the retained system can use. A billing application that calculates charges from completed warehouse activity is another possible example, with its own reconciliation needs.

When the extension starts becoming another WMS

Now suppose the proposed returns application must also decide which stock is available for orders because the WMS cannot represent the required states. It then needs to account for reservations and stock movements happening elsewhere. If it also starts directing normal picking and dispatch, the project is taking on the warehouse’s core execution responsibilities.

Keeping both systems may still be possible, but the sponsor should ask what the old WMS now contributes and what it costs to keep their decisions consistent. A small application’s initial scope can conceal a large ongoing operating responsibility. Staff reconciling different availability figures are doing part of that integration themselves.

Compare a wider replacement when a coherent part of the operation would work better under one system’s responsibility. Define that scope in operational terms, such as receiving through stock allocation and dispatch. Replacing warehouse execution does not automatically require replacing finance, payroll or every application in an ERP suite.

The number of workarounds alone is a poor guide. Several independent reporting gaps might be straightforward to address. One gap in stock availability can affect every order. Judge which decisions are affected and how often work has to cross the proposed boundary.

How Keel can support either scope

Keel is an operations platform that can be shaped around the work you want the team to do. For the returns service above, a Keel implementation could organise assessments and follow-up work around each receipt, give the assessor the relevant information and show the lead where returns are waiting. The team could change how the service is organised while keeping a clear outcome for the retained WMS.

Keel’s flows connect operator steps with processing, and its tools can provide filtered views of the work. The assessment rules and WMS connection would be implemented using business logic in code. The intended result is a usable operational service with a defined handoff. Its sequence, stock-state mapping and recovery behaviour need designing and testing for your WMS.

If the scope decision points to replacing warehouse execution, evaluate Keel against that wider work. Include routine receiving, stock movements and dispatch in the implementation scope, alongside the process improvement that prompted the project. Keel leads implementation and agrees customer handover; the scope determines what is delivered and what the retained systems continue to do.

Fund the boundary and the transition

Before approving the project, ask for a clear account of what stays in the WMS and what moves. For the returns example, that should let you identify the owner of a receipt, an assessment and a stock-availability decision without assigning the same decision independently to both systems. Name who owns the process and who supports the connection after launch.

Compare implementation and ongoing effort together. Configuration still needs setup and training. An extension adds a connection to maintain. Replacement brings migration and cutover work, and may remove interfaces or manual work that you currently pay to sustain. Ask for the costs and assumptions in your own scope, including internal staff time and future changes to the process.

A phased transition needs a definite unit of work to move. If you start with returns for one client, establish how receipts already awaiting assessment will finish and when new receipts begin using the new process. Agree how the team will check stock records, deal with failed updates and stop the rollout if the results do not reconcile. A smaller first phase helps only when its boundary is understood.

Once that scope is credible, use the warehouse software selection guide to compare implementation proposals and the WMS demo checklist to test the proposed work.

Discuss an extension or replacement with Keel. Bring the process you want to improve, what the current WMS does well and the decisions you think need to move.