Start from the jobs, not the menu
A core system is the one a normal day runs through: the ERP, the CRM, billing, the ticketing queue, the phone platform. Modernizing it fails in a familiar way. The new product is turned on beside the old one. People keep the path that already works, including the spreadsheet, the side inbox, and the person everyone asks. The purchase is new. The work is not.
Before you compare replacements, list what the current system actually does, including the jobs that never made the menu. Sit with the people who use it on an ordinary week. For each job, write the trigger, the person who does it, the screen or spreadsheet they open, and what done looks like.
A billing group, as an example and not a client story, often finds the figure that reaches the customer is finished in a sheet the system never stores, because an exception lives with one person. That sheet is part of the system. Leave it off the inventory and the new platform will not do the job. The sheet will outlive the cutover.
If you cannot name the person for each job, you are not ready to compare products. The inventory is the assessment.
Map every flow and name one owner
Draw every path data takes in and out. Include the manual ones: a file someone pastes, a nightly export, a chat message that stands in for a status change. For each path, write where it starts, where it ends, how often it runs, what goes wrong when it is late, and who may change it. One name. A shared mailbox is not an owner.
Mark the paths that carry a customer, an order, an invoice, or a ticket someone is waiting on. Those go first. A report can wait.
The map is also the list of what must exist on the far side before anything moves. A path with no owner is the first repair, and it is a workflow problem before it is a migration.
That map is the starting point of workflow and systems design: the current state, the handoffs, and who holds each boundary.
Retire, keep, or rebuild
Sort every job and every flow into one of three piles, and write the pile on the inventory.
Retire what exists only because the old system required it, or because nobody has asked whether it still matters. Check with the person who does it, then stop it before the move. Carrying a dead step forward gives the new system a screen nobody opens.
Keep what still does the job, when the pain is the bridges around it. Connecting what should stay, and retiring what is unused, is a complete project. Replacing the platform is the last resort, not the opening move.
That is how business systems modernization is scoped: the backbone the work needs, not a new product for every box.
Rebuild what has to continue and cannot stay where it is. Say what the rebuild is. A module in the next platform, a small integration, or a written step a person still owns. Name who runs it after the people who built it have gone.
Do the sort on the inventory, not in a demo. A platform asked to absorb everything on day one usually replaces the menu and leaves the jobs where they were.
Clean the records before they move
Take the records people still use, and leave the rest. With the people who trust the data, write what a complete record is: the few facts the next person is allowed to assume. Then look at what you actually have. Duplicates. Blank owners. Statuses that no longer mean what they say. The same customer under two names, one of them only in a sheet.
Fix that in the source, or in a staging pass, before the load. A cleanup after go-live is how a new system earns a reputation for being wrong.
Decide what you will not bring. Notes nobody opens, test rows, and years of attachments can sit in an archive with an owner. The new system does not have to hold every old workaround.
Load a slice first: one team, one product line, or a short stretch of recent records. Have the person who does the job open the result and mark what is missing. That list is the rest of the cleanup.
If the record is a customer handed from one team to another, name the record and the states on paper before anyone adds a field. Mapping a CRM handoff is that pass: the minimum facts, the states, then a test on real deals.
Run in parallel, or cut over in phases
Choose from the risk on the path, not from how a launch should feel.
A parallel run keeps the old path and the new path both available for a window you write down. Use it when a wrong record would reach a customer, or when an invoice or a ticket moves on that path. Write the date the old path stops being the backup people quietly prefer. During the window, one system is the record. If both accept edits, they drift, and the window turns into a reconciliation project.
A phased cutover moves one job, one team, or one flow, and leaves the rest where they are. Use it when the jobs can be separated, and when a smaller move will show you the real shape of the work. Each phase should remove a manual step someone does today, and stay small enough to undo.
Moving everything on one date fits only when the inventory is short, the records are clean, and the people who do the work have already run the new path. If any of that is still open, the plan is hope. Set the date with the people who will answer for the work that day.
Write the rollback before the date
A rollback is a decision you make while it is quiet. The signal that means stop. The person allowed to call it. The steps that put the old path back in front of the people doing the work.
Three parts are enough. The trigger: what you will see that means the new path is not safe to keep using. The owner: one person who can call it without assembling a meeting. The way back: how orders, tickets, or calls return to the system you still trust, and what happens to records created on the new side during the window. If you cannot describe the way back, you do not have a rollback.
Walk through the call once, on the access you will actually use, before the person who knows the exception is out. If you do go back, fix the cause before you name another date.
Decide what adopted means
The new system is adopted when it is the place the job happens, including the jobs that used to live in the sheet. Pick the measures from the inventory, before the cutover, and write them down. You choose them. Ignore a target printed on a vendor slide.
A short list a team can check: the side spreadsheet has a last edit and no new ones; the manual bridge for that flow has stopped; a named owner can add or change a user without calling the project; the person who does the job can finish it without opening the old system.
Review the list on a date you set, with the owners of the flows. If a sheet is still the real record, the project is not finished. The next piece of work is the job on that sheet.
Someone has to own that review after the people who ran the move return to their other work. A training session does not own anything.
The distance between a purchase and daily use is the subject of why most technology adoption fails: an outcome defined first, the workflow rebuilt around the tool, and a person who keeps looking after go-live.
Bring the inventory and the flow map to a strategy assessment. The agenda is which jobs move, which stay, and what would make you turn back.