Sorting Your WMS Customizations Before an Upgrade

A WMS upgrade with customizations is a different project than a clean upgrade. The platform move itself is usually fast: a clean move from one version to the next, with the vendor’s own migration tooling doing the work on the base product, often quoted in hours.

What that kind of estimate does not cover is the customizations themselves. Every custom workflow, every wrapper, every trigger someone added over the years to make the system do something standard product did not do yet still needs a decision before the upgrade goes live. That review is manual, and on a system that has been running for a decade or more, it is often the larger piece of the project.

We call this process mod disposition: sorting every customization into one of three outcomes before the upgrade starts, so the review has a shape instead of a pile. You will sometimes hear it called enhancement disposition too. We use mod disposition because that is the term our consultants use on the floor.

What a Mod Is and Why Older Versions Have So Many

A mod, short for modification, is custom code added to a WMS to change how it behaves: a wrapper around a standard function, a trigger that fires on an event, a workflow built to handle something the base product did not. That kind of extensibility, the ability to bolt custom logic onto a standard system, is what let WMS implementations solve problems the vendor had not gotten to yet.

On older WMS versions, that kind of extensibility was easy to use, and it stayed common practice for a long time, especially on systems that have been running for over a decade, where customizing rather than waiting on a vendor fix became the default way of working. Customers added mods to handle particular labor rules, unusual putaway logic, specific label formats, and integration quirks, one project at a time, for years. The product supported it, and it solved real problems. But every one of those WMS modifications is still running in the environment today, and none of them came with a note telling you whether the current version already does the same job. Multiply that across a decade of projects, and a WMS upgrade with customizations like these becomes its own kind of project, separate from the platform move itself.

What an Upgrade Estimate Covers, and What It Leaves to You

The upgrade estimate you get quoted is a configuration estimate. It assumes a clean move from one version to the next, with the vendor’s own migration tooling doing the work on the base product. It does not assume a system full of customer-built enhancements layered on top, because there is no way for that tooling to know what those enhancements are or whether the new version has already absorbed their function.

That is the gap. Nothing in the standard upgrade path compares your current mods against the version you are moving to. Someone has to do that work, mod by mod, and until recently the only way to do it was to read the code and the release notes side by side and make a judgment call. It is also where an upgrades and optimizations engagement typically starts, before a single line of code moves.

The Three Dispositions: Remove, Upfit, or Needs More Information

Every mod we have reviewed across these projects lands in one of three places.

• Remove. The destination version already does what the mod was built to do. Standard product caught up. The mod comes out, and one less thing has to be tested, maintained, or explained to the next person who inherits the system.
• Upfit. The mod still does something standard product does not, so it moves forward with the upgrade, reworked to run on the new version. Depending on the platform, that can mean real code work rather than a settings change: rewriting the mod’s logic in whatever scripting or extension framework the current version uses, and bringing it up to the vendor’s current coding standards.
• Needs more information. The documentation is thin, the original author is long gone, or the code does not make its purpose obvious. The mod cannot be sorted yet, because nobody can confirm what it is actually for.

That third category is the one people underestimate. On a system running for over a decade, undocumented mods show up constantly.

How the Review Works by Hand Today

Say an environment carries 47 mods, a number used here to illustrate the shape of the work, not a count from any real project. Each one gets the same three questions: does the destination version already cover this, does it need rework to survive the move, or is there not enough information to say either way.

One of those 47 might be a custom putaway rule written years ago that the platform has since absorbed into standard configuration, which gets removed. Another might be a label-printing trigger tied to a format the customer still uses, which gets upfit. A third might be a wrapper nobody has touched since the person who wrote it left the company five years ago, which needs more information before anyone can decide.

Multiply that across 47 mods, and the review becomes a release-notes-and-code-reading exercise that runs for weeks. It is easy to put into words: “Hey, I’ve got a 2012 system with years of wrappers and triggers and no list of what they do.” That is what a decade of extending a system without a review process looks like.

How Longbow’s Mod Disposition Tool Narrows the Review

We built a tool to narrow that review. It takes two inputs: the customer’s current enhancement inventory and the release notes covering every version between the source and the destination. It compares the two and returns a disposition for each mod, remove, upfit, or needs more information, based on what the release notes say standard product now does.

Our consultants still review what the tool flags. A tool that compares code against release notes can tell you a function exists in the new version. It cannot tell you whether your business still needs the mod’s specific behavior, or whether a needs-more-information result means thirty minutes of digging or three days. That judgment stays with the people running the upgrade assessment.

The tool is in beta and in testing on live projects right now. We built it because we were doing this work by hand on project after project, and a repeatable first pass made sense before anyone opened a single file.

Why Waiting Adds to the Review

The review does not get easier with time. We have seen a fix ship in one release while a customer’s environment had already moved many releases ahead, deferring new versions along the way. By the time anyone looked at the original fix again, the backlog of deferred testing behind it had grown substantially.

Every version you skip is another set of release notes to read against your mods, and another chance that a mod which used to be necessary became redundant several releases ago, but nobody noticed.

What to Have Ready Before the Review Starts

A WMS upgrade with customizations moves faster when a few things are gathered ahead of time:

• A complete inventory of current enhancements
• The code and whatever documentation exists for each mod
• The source version you are on and the destination version you are moving to
• The release notes covering every version in between

Customers who gather these four things ahead of time cut real time off the front of the project, because the review starts comparing instead of starting with discovery.

Sorting customizations before a WMS upgrade comes down to three outcomes: a mod gets removed because the new version already covers it, gets upfit to survive the move, or needs more digging before anyone can decide, right? The sooner that sorting happens, the smaller the surprise once the upgrade project actually starts.

If upgrades keep slipping, Longbow’s Managed Services team handles release management, monitoring, and continuous upgrades, so the version gap, and the mod backlog that comes with it, has less room to grow.

Frequently Asked Questions About Upgrading a WMS with Customizations

What happens to customizations during a WMS upgrade?

Each customization gets evaluated against the new version and sorted into one of three outcomes: removed if the new version already covers it, reworked (upfit) if it still serves a purpose, or flagged for more information if the documentation is too thin to decide. That review, sometimes called mod disposition, is what makes a WMS upgrade with customizations take longer than a clean upgrade.

What is a mod in a WMS?

A mod is custom code added to a WMS: a wrapper, a trigger, or a workflow built to change or extend standard behavior.

What is mod disposition?

Mod disposition is the process of sorting every customization in a WMS into one of three outcomes before an upgrade: remove, upfit, or needs more information.

What are the three possible dispositions for a mod?

Remove, when the destination version already covers the mod’s function. Upfit, when the mod is reworked to survive the move. Needs more information, when documentation or code is too unclear to decide yet.

What does upfit mean in a WMS upgrade?

Upfitting means reworking a mod’s code and logic so it runs correctly on the new version, often moving it from an older scripting approach to whatever the current platform uses, and bringing it up to the vendor’s current coding standards.

Does mod disposition replace the manual review of enhancements?

No. Mod disposition narrows the manual review by comparing mods against release notes before anyone opens a file. Consultants still review what the tool flags and make the final call.

What do I need in hand to start a mod disposition review?

A complete enhancement inventory, the code and documentation for each mod, your source and destination versions, and the release notes covering every version between them.

How far along is Longbow’s mod disposition tool?

It is in beta and in testing on live upgrade projects now.