A specialty chemical company with forty employees, three production lines, and one warehouse has been running its operation on a network drive full of spreadsheets since 2018. The master inventory workbook has eleven tabs and three people who understand all of them. The BOM workbook is maintained by the plant engineer and updated when someone remembers. The purchase log is a shared Google Sheet that the procurement lead treats as a diary. The CEO signs off on a manufacturing software purchase in January and tells the operations team to be off spreadsheets by the end of the quarter. The operations team agrees in the meeting and then quietly panics for a week. The problem is not the new software. The software works. The problem is the migration path. What gets imported, what gets re-entered, what gets left behind, and how the team keeps running production during the switch. This is where most small manufacturer software rollouts slip their deadlines. Not because the technology fails, but because the migration plan never existed on paper. A realistic spreadsheet to MRP migration for a small manufacturer takes about sixty days if it is planned carefully, longer if it is not. Here is what those sixty days should look like.
Why Sixty Days Is the Right Window
Small manufacturers under two hundred employees tend to have enough complexity to need a real system and enough simplicity that a sixty-day timeline is achievable. Larger organizations take longer. Smaller ones could go faster but rarely do, because cutover risk is disproportionately higher when one missed production run represents a meaningful slice of monthly revenue.
Sixty days breaks roughly into three phases. The first thirty are setup and data import. Days thirty-one to forty-five are parallel operation. Days forty-six to sixty are cutover and stabilization. For a manufacturer with fewer than five hundred SKUs and a single site, sixty days is generally achievable. For more complex operations, the same framework applies but each phase takes longer.
The case for real-time inventory over spreadsheet-based tracking is made in the piece on why spreadsheet inventory fails at scale. Spreadsheets are useful right up to the moment they become the single biggest risk to production, and at that point the migration is no longer optional. The only question is how to do it without breaking anything while the transition happens.
Days One Through Ten: Master Data and Structure
The first ten days are spent on master data and system structure, not on any inventory transactions. This is counterintuitive to teams that want to see stock moving through the new system immediately, but the structure has to be right before transactions start, or the transactions will reinforce bad structure.
Master data starts with items. Every SKU the operation handles needs a clean record: SKU code, description, unit of measure, item type (raw material, finished good, sub-assembly, packaging), and initial cost. The SKU code has to be unique per organization, which sounds obvious until someone realizes the spreadsheet has three versions of "PET-250" with slightly different capitalization. Data cleanup happens here, not after import. A dirty item master will pollute every downstream process.
Locations come next. For a single-site operation, the hierarchy is typically a warehouse for raw materials, a factory floor for production staging, a finished goods bay, and a dispatch area. Typed locations give each one the appropriate operational semantics. The location hierarchy should be set up to match the physical flow of material through the plant, because this is the structure that every future report, alert, and permission will inherit.
BOMs are the third piece of master data. Every active finished good needs a BOM with every component, the quantity per unit, and the waste percentage. If the spreadsheet version of the BOM has inaccuracies (and it almost always does, especially in the waste percentages), this is when to fix them. Imported BOMs that carry their spreadsheet errors into the new system produce production variance that looks like operator error but is actually data error, and that is a painful diagnostic to run six months into using the new platform.
Suppliers, users with roles and scopes, and custom fields round out the first ten days. By day ten, the system is a complete structural shell with no transactions yet.
Days Eleven Through Thirty: Inventory Load and Validation
Days eleven through thirty are for loading inventory and validating that the loaded data matches the physical reality. This is the most error-prone phase of any excel inventory replacement, because the spreadsheet version of current stock is almost never accurate enough to import directly.
The recommended approach is a physical count at the start of this window. A count takes a day or two of dedicated effort at most small plants and produces the cleanest possible starting balance. The counted quantities become the opening stock records in the new system, entered via initial inbound movements that establish the baseline. Every subsequent movement is recorded against that baseline, which means the ledger has a clean starting point.
Skipping the physical count and importing the spreadsheet's stock values is a common shortcut that almost always costs more time than it saves. Whatever discrepancies exist in the spreadsheet get imported into the system, and the first few weeks of real operation are spent tracing them. The physical count avoids this by establishing ground truth before the new system starts accumulating its own history.
Historical transactions are a separate question. Most small manufacturers do not need a full movement history imported. The starting balance is enough. Historical data can be archived in the spreadsheets for reference. The new system's ledger starts fresh at the load date, which keeps the import tractable.
Validation happens throughout. Random spot checks compare system balances to physical reality for a sample of items daily. Any discrepancies get investigated and corrected. By the end of day thirty, the team should have high confidence that the system's view of inventory matches the real warehouse.
Days Thirty-One Through Forty-Five: Parallel Operation
This is the most important phase of the migration and the one most teams skip. Parallel operation means running both systems simultaneously against real production. Every receipt, every transfer, every production run, every adjustment gets recorded in both the spreadsheet and the new platform. At the end of each day, the two are reconciled.
Parallel operation is expensive. It doubles the data entry burden for two weeks. The team will resist. The case for it is that this phase is the only place the new system gets tested against real operational complexity before the spreadsheet goes away. Bugs, training gaps, and process weaknesses surface here, while the spreadsheet is still available as a fallback. Skipping this phase means the first time the new system handles real production without a backup is the day after cutover.
During the parallel phase, specific scenarios should be deliberately tested. A full production run from order creation through run completion. An inter-area transfer from warehouse to factory floor. A receipt against a purchase order with a quantity variance. An adjustment with a documented reason. An alert firing and being resolved. Each scenario reveals a different aspect of the system and a different part of the team's capability with it.
Role-based rollout matters during parallel operation. A staged rollout (plant manager and a lead warehouse operator first, production supervisors in week two, remaining operators and viewers in week three) gives the team time to build internal expertise before the full organization depends on the platform. The users onboarded first become the internal support resource for everyone who follows.
MRP implementation plan details often emerge during parallel operation. The MRP engine needs a planning horizon, and the right choice depends on production cadence and supplier lead times. The piece on MRP planning horizons discusses the tradeoffs. Most small manufacturers settle on thirty days as a default and tune from there.
Days Forty-Six Through Sixty: Cutover and Stabilization
Cutover is the day the spreadsheet stops being the source of truth. Announce a specific calendar date at least a week in advance, and do the cutover at a moment of low operational stress, such as the start of a Monday morning.
The go-live checklist is specific. Open purchase orders migrated with their expected receipt dates. Confirmed production orders entered with their BOM versions locked. Pending transfers set up as pending records. Users active with their scopes verified. Final physical count reconciled against the system balance. Alert thresholds tuned from parallel operation data. Notification preferences configured per user.
The spreadsheet does not get deleted on cutover day. It is archived and kept read-only for at least sixty more days. This inventory cutover fallback lets the team answer "how did we handle this before" during the first two months of exclusive use.
Stabilization during the final fifteen days means watching for specific patterns. Alerts that fire too often need threshold tuning. BOMs with persistent run variance indicate BOM accuracy problems. Transfer discrepancies reveal process gaps at receipt. Users falling back to spreadsheet habits indicate training gaps. Each pattern gets addressed individually. By day sixty, the system should feel native rather than foreign.
What Makes the Sixty-Day Plan Work
Three properties of the underlying platform make this timeline realistic. Event-sourced inventory means every stock change creates an immutable movement record, so the ledger accumulates cleanly from day one of the physical count. The piece on immutable audit ledgers explains why this property matters. The migration benefit is that there is no "pre-system" data to reconcile against after cutover.
Deterministic MRP means planning calculations are reproducible and explainable. A planner can see why the system is recommending a particular purchase order and trace it back to the production orders driving the demand. That transparency is what lets a team trust the system's recommendations during the early weeks. The piece on moving from reactive to predictive procurement discusses the shift in more detail.
Role-based rollout with scoped permissions keeps the training burden manageable. A warehouse operator's interface is simpler than a plant manager's because the operator's role and scope filter what is shown. The training conversation for each role is correspondingly narrower.
Avoiding the Common Failure Modes
Three failure modes account for most missed timelines. The first is skipping the physical count. The second is skipping parallel operation. The third is underestimating master data cleanup. Each of these shortcuts looks like a time saver in the moment and costs weeks of stabilization work after cutover.
A fourth failure mode is organizational: assigning the migration as a side project to someone with a full operational role. The migration needs a dedicated owner for the full sixty days, with enough authority to pull users into training and enough bandwidth to handle daily reconciliation during parallel operation. A migration with no owner stalls around day twenty, when initial enthusiasm fades.
Small manufacturers that complete this plan successfully tend to describe the sixty days as surprisingly uneventful. The lack of drama is the sign of a well-executed migration, the result of spending the first ten days on structure, the next twenty on clean data, the next fifteen on parallel validation, and the final fifteen on controlled cutover. Done in that order, the spreadsheet to MRP migration stops being a risky project and becomes a scheduled operational activity.
FalOrb supports small manufacturers moving off spreadsheets with event-sourced inventory, deterministic MRP, role-based rollout, and a sixty-day implementation path that keeps the old system available as a fallback until cutover. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation. More at falorb.com.