The technology is rarely the hard part
Most mid-sized employers know when a core system has aged out. It will not connect to newer tools, reports take a day to build by hand, and only one or two people really understand how it works. The decision to replace or rebuild gets made. Then the project stalls, because the team to carry it out does not exist.
This post is about that gap. If you are a controller, operations lead or owner looking at an ageing ERP, a batch payroll system or an in-house database, the staffing plan matters as much as the technical one.
Signs the system is costing you more than it saves
You do not need an audit to spot the pattern. Look for these:
- Month-end close depends on exports, spreadsheets and manual reconciliation.
- Your plant or warehouse floor works around the system instead of through it.
- Nobody can answer a simple question about live inventory, orders or margin without a request to IT.
- Vendor support has ended, or patches have stopped.
- One person holds most of the knowledge, and that person is within a few years of retirement.
That last point is the one owners tend to underrate. In both Canada and the US, a large share of the people who built and maintained older systems are approaching retirement. Replacing the software without capturing what they know is how data errors and broken processes get carried into the new platform.
Choose the approach, then choose the people
The options run from moving the existing system to new hosting, through reworking parts of it, to a full rebuild or a switch to off-the-shelf software. Each one calls for a different mix of people.
- Moving or lightly reworking: mostly infrastructure and systems administration skills, with a smaller development component.
- Rebuilding in-house: developers, a solution architect, testers and a product owner from the business side.
- Buying and configuring a package: an implementation lead, data migration specialists and analysts who can translate how your operation really runs into settings and workflows.
A common mistake is to approve a budget for software and licences and nothing for the 6 to 18 months of specialist labour around it.
Contract talent suits most of the project
A modernization project has a peak and an end. You need heavy development, data migration and testing capacity for a defined stretch, and much less afterward. That shape fits contract and contract-to-hire staffing well.
A sensible split looks like this:
- Contract: developers, data migration analysts, QA testers, project managers, cutover support.
- Permanent: the architect or technical lead who will own the system for years, and the internal administrator who keeps it running.
- Existing staff: the process experts. Your accounting, production and logistics people must be in the room, because they know the exceptions.
Contract-to-hire is useful for the lead roles. You see how someone handles your data and your politics before committing to a permanent seat.
Where AI and data skills fit
Many modernization plans now include reporting, forecasting or automation that the old system could never support. That is a reasonable goal, but it depends on clean data. Budget for a data engineer or analyst early, before the new platform is live, to profile and clean what you are moving. Adding an AI use case on top of messy records produces confident, wrong answers.
Be specific when you hire. A person who has built dashboards is not the same as one who has designed a data model for production use. Ask for examples of migrations they have actually completed.
Plan for the finance and operations side
Three items are often missed:
- Parallel running. Finance teams usually need one or two closes on both systems. That is extra workload on people who are already busy, so backfill it with temporary accounting or operations staff.
- Training time. Shop floor and office users need hours away from their jobs. In manufacturing, that means planning around production schedules.
- Knowledge capture. Document the retiring expert's workarounds before cutover, not after.
A staged approach can cost more
Spreading a rebuild across several small phases feels safer. It often means paying twice for integration work, keeping two systems alive longer and holding a contract team on retainer for years. Staging still makes sense when the business cannot absorb disruption, but price it honestly against doing the work in one planned push.
What to do next
Before you sign with a software vendor, write down the roles the project needs, which are contract and which are permanent, and when each must start. Identify who holds the undocumented knowledge today. Then check whether you can fill those seats in the time your plan assumes.
Traverse has placed contract and permanent technology, finance and operations people since 1997, and a recruiter can help you scope the team for a modernization project.