End Lift and Shift Implementation: Why AI Gives Finance Room to Rethink

In a lift and shift implementation, the new system is configured to reproduce the old one with as few changes as possible. Stanton House, an ERP consultancy, describes the approach as replicating existing processes in the new system with minimal changes, with the focus on getting the technology live quickly.

The same pattern shows up in billing, revenue and quote-to-cash projects. Discount rules, contract exceptions and manual adjustments move across because nobody has time to ask whether they still make sense. No one decides to copy everything. It happens one deadline at a time.

A lift and shift is not always the wrong call. A vendor contract may end, or an audit date may be fixed, and speed has to win. The trouble starts when the copy becomes the whole plan and the redesign that was supposed to follow never gets scheduled.

Implementation has long set the pace of change. Teams move at the speed of discovery, data mapping, migration and manual validation, which is not always the speed the business needs. When the calendar tightens, redesign is the first thing to go because it is the easiest work to postpone.

A few pressures push teams toward a copy:

• Discovery takes weeks, and the answers sit in contracts, spreadsheets and people’s heads.
• Data has to be mapped and cleaned before anyone can see how the new system will behave.
• Validation is manual, so every change request adds to the schedule.
• Go-live dates are tied to audits, renewals or a retiring system.

Under that pressure, the team can only afford to reproduce what it can already describe. The exceptions nobody documented get copied too, because they are part of how invoices go out today.

The cost shows up after launch. Stanton House notes that copying legacy processes that were never optimized builds inefficiency into the new system, and that users then return to manual workarounds, spreadsheet trackers or shadow IT. The system changes. The behavior around it does not.

For finance teams, the effects are easy to recognize:

• Manual adjustments stay in spreadsheets, outside the system of record, so audit risk stays where it was.
• Pricing changes still need a project, because the new system was configured around today’s offers.
• Close takes the same effort, since the same reconciliations run every month.
• The team funds a second project to do the redesign it skipped.

There is also a timing cost. A postponed redesign rarely returns to the plan on its own, because the live system now carries real customers and real close deadlines, and every change carries risk it did not carry before go-live.

The same logic applies to architecture choices. Moving order-to-revenue customizations into a new ERP unchanged rarely fixes the underlying problem, as this guide on decoupling order-to-revenue from the ERP explains.

Not every old rule is a mistake. Some exist because a customer needs them, an auditor expects them or a contract requires them. The goal is to separate those from habits that built up over time. For each term or step you find, ask four questions:

1. Does a customer, a contract or an accounting rule require it?
2. Can the new system handle it as standard behavior, or does it need a custom workaround?
3. Who owns it, and would that person defend it today?
4. What breaks, and who notices, if we retire it?

Take a simple case. A legacy account carries a 10 percent discount that starts in year two, entered by hand because the old system could not express it. If the contract states the discount, the new system should model it properly. If the discount lives only in a spreadsheet note, someone needs to confirm it before it follows the customer into the new system. Either way, a person made a decision on purpose, which a straight copy never asks for.

You do not have to pick between a fast project and a good one, but you do have to sequence the work. Redesign needs to happen before configuration, and it needs real data to be useful.

1. Start with a sample of real contracts, order forms, amendments and invoices, and mark each term as standard, a deliberate exception or a leftover.
2. Decide what to keep, simplify or retire, and write each decision down with an owner.
3. Build a working model from those decisions and test it on your own data before full configuration starts.
4. Reconcile early. Compare outputs with the legacy system on sample accounts so differences surface while changes are still cheap.
5. Phase the rollout by product or region where you can, and keep the model as the base for later changes.

The order matters more than the tooling. A team that sorts its exceptions first gives every later step something concrete to check against, and it can say yes or no to a change request without reopening the whole design.

Much of the time lost in implementation goes to reading, mapping and reconciling inputs by hand. AI can take on a large share of that preparation work. It can read contracts and order forms, propose mappings, flag differences and rebuild a model faster than a team can do it manually.

It does not replace judgment. Eric Bodge, the VP and Controller at ConstructConnect, described the split this way: “AI can save time producing the what so that humans can focus on the more value-added why.”

That is a useful standard for any AI-assisted project. Look for these things:

• You work with your own data early, not generic templates.
• Experts review and approve each step before it affects your configuration or your books.
• Every mapping and change leaves a trail an auditor can follow.
• The working model stays available after go-live, so later pricing changes and new business units start from context instead of from scratch.

The goal is governed flexibility. The AI handles repeatable work, and finance and implementation experts stay responsible for decisions, controls and sign-off.

The best outcome of a redesigned implementation is more than a clean first launch. It is a working model of how the business sells, prices and bills, which the team can keep using. When pricing changes, a new business unit joins or an integration has to move, the team starts from that model instead of a blank page.

That changes how finance thinks about the next project. A pricing test becomes a change to a model the team already understands, not a new project with its own discovery phase. An acquisition becomes a data load against a known design. The cost of change drops because the context was never thrown away.

To make that work, keep the documented decisions on exceptions, the sample data used for testing and the reconciliation checks current after go-live. A model that nobody maintains turns back into tribal knowledge.

We help finance teams avoid a lift and shift implementation. Milo, our implementation agent, builds a working quote-to-cash model from the contracts, product and pricing files and invoices you already have, so your team can see the design and change it before configuration begins, with Zuora experts and your team reviewing key decisions. ConstructConnect had a live sandbox with its own data one day after signing, and Fullsteam now onboards five to six business units every other month with one full-time employee. See how Milo works on your own data and decide what is worth changing before go-live.