Case study · Manufacturing & distribution
Replacing a 35-year-old ERP without stopping the orders
A US operator that runs orders, production, warehousing and collections for footwear brands depended on an ERP written around 1990: half a million lines of code that nobody dared touch. We mapped it, rebuilt the operation as a multi-company platform on top of NetSuite, and audited the warehouse system another vendor had left behind.
In numbers
35+
years of business rules mapped before a line was written
13
modules following the physical flow, from line sheet to credit note
~50
transactions was where the inherited warehouse code broke; the audit found it first
Who this is for
Owners and directors of distribution or manufacturing businesses whose operation depends on a system nobody dares touch, and who need to know what a replacement really involves before committing to one. You will get the sequence we used, map, audit, decide, pilot, and the specific failure modes we found in inherited code, so you can ask the same questions of your own.
Key takeaways
- Map the rules before choosing the tool. Thirty-five years of logic lived in FoxPro code and in people's memory. Reading the code process by process is what made a replacement safe.
- Inherited work gets audited, not extended. The abandoned warehouse system had a hard ceiling at around 50 transactions. Finding that first turned an open-ended development effort into a scoped decision.
- A platform on top, a system of record beneath. Not a new ERP and not a customised NetSuite: a layer written for footwear wholesale, with NetSuite doing what it is good at.
- Sequence is part of the design. One pilot brand went live first while the legacy system kept running. That is why no order stopped.
- We publish what we can prove. Hours saved, error rates and cycle times are still being counted, and will be added when the client has them.
What do you find when you open a 35-year-old ERP?
An operation that runs end to end on code from 1990
The company sits between footwear brands and the stores that buy from them: it creates the seasonal catalogues, takes orders by hand and by EDI, coordinates factories in Asia and Europe, receives containers into two warehouses, allocates stock, releases shipments, invoices, and collects through a credit factor. Every one of those steps ran through an ERP built in FoxPro around 1990: more than 500 programs, over 600 tables per company, and decades of business rules that existed nowhere else.
The problem was that it worked
The system worked. That was the problem. It handled EDI with national retail chains, multi-warehouse inventory, packing and carrier labels, and several legal entities, and nobody could say with confidence what would break if any of it changed. Around it had grown the usual scaffolding: spreadsheets, email threads with factories and forwarders, a BI tool, and a NetSuite instance that held finance but not operations.
The owner's real question
A previous vendor had started a warehouse management system on NetSuite and left. The owner's question was not “which software should we buy”. It was: how do we get off this without stopping the orders, and how much of what we already paid for is worth keeping?
Reading the business and the code the same way
Understanding took longer than anyone wanted. We documented the business as it is: the actors (brands, stores, factories, warehouses, forwarders, carriers, customs brokers, the credit factor), the order types, the approval points and the exceptions. Then we read the legacy code the same way, mapping programs and tables to the processes they served, so whatever came next would preserve the rules and not just the screens.
Build, buy or rebuild: what did we decide, and why?
A platform for the trade, NetSuite beneath it
The decision was to build a private, multi-company operating layer for the business and to make NetSuite the system of record beneath it. Not a new ERP, and not a customised NetSuite either: a platform written for the footwear wholesale trade, with NetSuite doing what it's good at.
What the audit of the inherited system found
The inherited warehouse system got an audit before a single line was added. We found working code and also serious risk: returns modelled outside NetSuite's native transactions, batch scripts that hit the platform's limits at around 50 transactions, database queries built by string concatenation, and integration roles with far more permission than they needed.
| Finding | Why it matters |
|---|---|
| Returns modelled outside NetSuite's native transactions | The system of record does not hold them |
| Batch scripts that hit the platform's limits at around 50 transactions | They break at an ordinary day's volume |
| Database queries built by string concatenation | An injection risk |
| Integration roles with far more permission than they needed | More access than the integration uses |
The recommendation, priced
The recommendation was to rebuild it as a versioned, event-driven SuiteApp: the scanner sends the operation, a queue validates and records it, NetSuite processes it in the background, and every error is logged and retryable. We wrote down the hours and the weeks it would take. The client decided with the numbers in front of them.
Why the order mattered as much as the shape
The sequence mattered as much as the shape. The rollout was designed in pieces the client could see and use, starting with one brand as the pilot, while the legacy system kept running.
What did we actually build?
A platform in thirteen modules that follow the physical flow: product and line sheets, customers, orders, production, receiving, allocation, releasing, shipping, returns and credits, payments, reports, notifications.
- Multi-tenant back end with role-based permissions and two-factor authentication, so each brand sees its own operation and the operator sees all of them.
- Typed API contracts and a QA backlog that validates the complete flow, from catalogue to release, before any module goes live.
- NetSuite as the source of truth for orders and master data beneath the platform.
The pilot brand's operation went live first: catalogue, orders, production, receiving, allocation and releasing run on the platform, and the legacy system kept running while they moved.
What has held since go-live?
Operations, finance and warehouse staff work from one system with one set of permissions; approvals that used to travel by email now leave a trail. The migration has not stopped an order.
Business rules that lived only in 1990 code and in people's heads are now documented, tested and owned by the client. The warehouse audit turned an open-ended development effort into a decision with a scope, a cost and a sequence.
The measurable part the client cares about most is still being counted: hours saved, error rates, cycle times. We'll publish them when the client has them.
Questions readers ask
Customer Success Team
Itaca Technologies
Your question isn't here?
Ask it as you'd ask it across the table. The team that does the work reads it and answers with a concrete next step.