Change Management During Migration: Getting Skittish Teams to Embrace New Interfaces

Introduction

ERP migration can be technically successful and still struggle after go-live if employees do not feel comfortable using the new system. Data may be migrated correctly. Integrations may work. Reports may reconcile and the new platform may technically support every required process. Yet users may continue keeping private spreadsheets, entering transactions late or asking colleagues to complete tasks on their behalf because the new interface feels unfamiliar.

This is why ERP change management should be treated as part of the migration rather than as a training activity scheduled shortly before launch.

Employees are not simply learning different buttons. They are often moving from workflows they have used for years into new processes with different screens, approvals, responsibilities and terminology. A sales employee who previously created an order in three steps may now need to follow a structured quotation workflow. A warehouse employee may need to record every movement in real time instead of updating a spreadsheet at the end of the day.

The objective of change management is therefore not to convince users that the new ERP is better. It is to help them understand how their daily work changes and give them enough confidence to operate the new environment without falling back on legacy habits.

For businesses planning an Odoo ERP migration this means involving users before cutover, providing role-based training and supporting employees through the first weeks of live operations.

Why Teams Become Resistant During ERP Migration

Resistance is often described as employees being unwilling to change. In practice the reasons are usually more specific.

Employees may worry that the new ERP will make familiar tasks more difficult. They may fear that automation will reduce their role. Some may be concerned that increased visibility will expose mistakes that were previously hidden inside departmental systems.

Others simply do not understand why the migration is happening.

If management communicates only that the company is "moving to a modern ERP" users may not see how the change benefits their work.

Consider a warehouse employee who has used the same inventory spreadsheet for seven years. The employee knows where every field is located and understands several informal workarounds. Replacing that process with a new Odoo Inventory interface may initially feel slower even if the new workflow is technically more efficient.

The first stage of change management is therefore understanding what users believe they are losing.

Start Change Management Before Configuration Is Finished

A common ERP implementation mistake is waiting until the system is almost ready before introducing it to users. By that point many important workflow decisions have already been made.

Employees then see the new system for the first time during training and may immediately identify practical problems. A stronger approach introduces key users earlier.

The migration process can follow:

Current Process Review → Key User Input → Future Workflow Design → Odoo Configuration → User Validation → Training → Cutover

This gives employees an opportunity to explain how work actually happens instead of allowing the implementation team to design the future environment only from management requirements.

The objective is not to let every user determine the ERP design. That can create excessive customization. The goal is to capture real operational knowledge before workflows are finalized.

Identify Who Will Be Affected

ERP migrations do not affect every employee in the same way.

Finance may experience changes in invoicing and reconciliation while warehouse teams may have new barcode or inventory workflows. Sales employees may work with new quotation screens and purchasing teams may follow new approval rules.

Change management should therefore begin by mapping user groups.

This allows training and communication to focus on actual job changes rather than providing the same generic ERP introduction to everyone.

Explain the Business Reason for the Migration

Employees need to understand why the organization is changing systems. Statements such as "the current ERP is outdated" may be technically correct but they do not explain how daily work will improve. Communication should connect current problems to future workflows.

For example:

Current Problem: Sales must call the warehouse before confirming stock.

Future Workflow: Inventory availability becomes visible from the connected ERP.

Another example might be:

Current Problem: Finance manually combines sales and inventory reports every month.

Future Workflow: Operational transactions flow into connected financial reporting.

When employees can connect the migration to problems they already experience the new system becomes easier to understand.

The message should be practical:

Current Friction → New Process → Expected Improvement

Document the Current Workflow Before Replacing It

One reason users become frustrated during migration is that implementation teams underestimate informal work.

The official process may say that purchase requests are approved by a manager. In reality employees may also send a spreadsheet to finance and notify procurement through email.

These hidden steps matter. Before redesigning a workflow the team should document the actual current sequence.

For example:

Employee Request → Spreadsheet → Manager Email → Finance Confirmation → Procurement Entry → Purchase Order

The future process may become:

Purchase Request → System Approval → RFQ → Purchase Order

The new workflow contains fewer steps but users need to understand which old activities disappear.

Without this explanation employees may continue sending spreadsheets and emails because they assume those actions are still required.

Create Change Champions Inside Each Department

Employees often trust experienced colleagues more than a project team that appears only during implementation. This makes departmental change champions valuable.

A change champion is a key user who understands both the existing process and the future ERP workflow.

The champion participates in testing and helps other employees understand how the system should be used. A useful structure may include a sales champion, purchasing champion, warehouse champion and finance champion.

These users can help identify practical issues before go-live and provide first-line support after launch. They also help translate technical implementation decisions into language that makes sense within each department.

The goal is not to turn champions into system administrators. Their role is to bridge the gap between the implementation project and daily operations.

Use Role-Based Training Instead of Generic ERP Training

A three-hour presentation showing every ERP module rarely creates confident users. Most employees need to understand only the workflows relevant to their role.

Sales employees should practice creating quotations, confirming orders and checking customer information. Warehouse employees should practice receipts, transfers and deliveries. Finance users should work with invoices, bills, payments and reconciliation.

Training should therefore be organized around tasks.

A practical learning sequence is:

Login → Find Required Record → Perform Daily Task → Handle Common Exception → Complete Transaction

Users should work with realistic examples rather than watching only demonstrations.

For example a purchasing employee can create a real-looking RFQ then convert it into a purchase order and receive the resulting transaction into inventory. This allows employees to understand how one action affects the next part of the process.

Show Users What Has Changed

Users should not be expected to discover process differences by themselves. A simple old-vs-new comparison can make training much easier.

This type of comparison reduces uncertainty because users can connect familiar activities with their replacement.

Create a Safe Practice Environment

Employees should be allowed to make mistakes before production go-live. A training or UAT environment provides a safe place where users can create transactions without affecting real accounting or inventory.

Users should practice realistic scenarios. A salesperson might create a customer quotation then confirm it. A warehouse employee can process the resulting delivery. Finance can then generate the invoice.

The training flow becomes:

Sales User → Sales Order → Warehouse User → Delivery → Finance User → Invoice

This is more valuable than teaching each module independently because employees see how their work affects other departments. It also reveals where users misunderstand responsibilities.

Use UAT as an Adoption Tool

User Acceptance Testing is normally viewed as a technical validation stage but it can also support change management. During UAT key users work with migrated data and realistic processes before production launch.

This helps users build familiarity while also identifying configuration problems. A strong UAT session should ask users to complete real business scenarios rather than simply confirm that screens open correctly.

For example:

Create Customer → Create Quotation → Confirm Sale → Reserve Inventory → Deliver → Invoice → Register Payment

The user then confirms whether the workflow matches the agreed future process. When employees participate in this stage they are less likely to encounter the entire system as a surprise during go-live.

Manage the Fear of Increased Transparency

ERP systems often increase process visibility.

Managers may be able to see when transactions were created or approved. Finance may see incomplete warehouse transactions and operations may see orders waiting for invoicing. Some employees may interpret this visibility as increased monitoring.

Management should explain that the purpose is process control rather than individual surveillance. For example if a delivery remains incomplete the system should help the team identify where the process stopped.

The organization should focus discussions on:

Transaction Status → Process Bottleneck → Corrective Action

rather than turning ERP reporting into a tool for blaming individual employees. A culture of blame can quickly encourage users to hide problems or maintain offline records.

Control Spreadsheet Workarounds After Go-Live

One of the clearest signs of weak ERP adoption is the return of spreadsheets. Not every spreadsheet should be removed. They remain useful for analysis and temporary calculations. The problem appears when users continue running operational processes outside the ERP.

For example sales may maintain a separate order tracker because employees do not trust the new sales screen. Purchasing may continue using a private supplier spreadsheet and warehouse teams may update stock manually outside the ERP.

These workarounds create a second operating system. The organization should monitor which spreadsheets remain after go-live and ask why they exist.

Each workbook can be classified as:

Analysis Tool → Keep

Temporary Transition Tool → Phase Out

Operational System → Replace With ERP Workflow

This prevents legacy practices from gradually rebuilding the fragmentation that the migration was intended to remove.

Prepare for the Productivity Dip

Even well-trained teams may temporarily work more slowly after ERP go-live. Employees are learning new navigation and new terminology while also performing normal business tasks.

Management should expect this transition. If employees are measured against full pre-migration productivity immediately they may become frustrated and search for shortcuts.

Instead the organization can monitor adoption over several weeks.

The goal is to move from correct usage to efficient usage.

Build a Structured Go-Live Support Model

Users need to know where to go when something does not work. Without a support model employees may create their own solutions.

A practical support structure can follow:

User Question → Department Champion → ERP Support Team → Technical Team

Simple process questions can often be solved by department champions. Configuration problems can be escalated to the ERP support team while technical defects move to developers.

Support requests should also be categorized. A problem may actually be a training issue rather than a software defect.

Common categories include:

How-To Question → Configuration Issue → Data Issue → Integration Issue → Customization Defect

Tracking these categories helps management understand whether the migration problem is technical or related to adoption.

Measure Adoption Instead of Assuming It

A system being live does not mean it has been adopted. Organizations should measure actual usage.

Useful indicators include transaction completion time, number of support tickets, number of spreadsheet workarounds, delayed entries and user error rates.

Managers can also compare whether business processes are actually moving through the intended ERP workflow.

If purchase orders are created correctly but approvals still happen through email the system has only been partially adopted.

A practical adoption measure is:

Configured Process → Actual User Behavior → Difference → Corrective Action

This turns change management into an ongoing improvement activity.

Change Management During an Odoo ERP Migration

For an Odoo ERP migration change management should be aligned with the applications being implemented.

A business may move from separate applications into:

Odoo CRM → Odoo Sales → Odoo Inventory → Odoo Purchase → Odoo Accounting

This creates connected workflows but it also changes how departments interact.

Sales employees may now see inventory information directly. Warehouse transactions may influence invoicing and purchasing activity may become more closely connected with stock requirements. Users therefore need to understand both their own application and the upstream or downstream effects of their actions.

Relevant project areas include Odoo ERP migration, Odoo change management, Odoo user training, Odoo ERP implementation, Odoo workflow migration, Odoo user adoption, Odoo customization and Odoo support services.

The objective should be to make employees comfortable with complete Odoo workflows rather than teaching isolated screens.

How Browseinfo Can Help Support Odoo User Adoption

ERP migration requires more than technical configuration. Employees need clear workflows and a system that reflects the agreed business process.

Browseinfo can support businesses through Odoo ERP implementation, Odoo migration, Odoo customization, Odoo integration, Odoo consulting and ongoing Odoo support services.

A transition can begin by mapping the existing process and identifying how each user group currently works. The future Odoo workflow can then be designed around required business steps.

For example:

Current Sales Process → Existing Workarounds → Future Odoo Sales Workflow → UAT → User Training → Go-Live Support

Browseinfo can help configure Odoo applications according to the agreed process while also addressing justified customization and integration requirements.

During testing key users can validate workflows before production launch. After go-live support can focus on identifying whether user issues relate to training, configuration, migrated data or technical defects.

The objective is not simply to place users inside a new Odoo interface. The objective is to help the organization move from old habits into consistent workflows that employees can use confidently.

Common Change Management Mistakes

One common mistake is beginning communication too late. Employees who learn about major workflow changes only during training may feel that the system was designed without understanding their work.

Another mistake is providing generic training. Users need role-specific practice that reflects daily tasks.

Organizations may also ignore experienced employees who are skeptical about the new ERP. These users often hold valuable process knowledge and involving them early can improve both system design and adoption.

Another major mistake is allowing legacy workarounds to continue indefinitely after go-live. Temporary spreadsheets can quickly become permanent shadow systems.

A stronger approach is:

Communicate → Involve → Design → Train → Practice → Support → Measure → Improve

Frequently Asked Questions

1. Why is change management important during ERP migration?

Change management helps employees understand new workflows and responsibilities while reducing the risk that users continue relying on legacy processes after go-live.

2. When should ERP change management begin?

It should begin during process assessment and workflow design rather than waiting until the final training phase.

3. What is the best way to train Odoo users?

Role-based training using realistic business transactions is usually more useful than broad demonstrations of every Odoo feature.

4. What are change champions in ERP implementation?

Change champions are experienced departmental users who participate in testing and help colleagues understand the new workflows.

5. How can businesses measure ERP adoption?

Businesses can monitor transaction completion, support requests, spreadsheet workarounds, error rates and whether employees follow the intended ERP workflows.

Conclusion

ERP migration changes more than software. It changes how employees perform daily work and how information moves between departments.

For organizations implementing Odoo ERP this approach helps employees understand how CRM, sales, purchasing, inventory, accounting and other applications work together. The objective should not be to force teams to accept a new interface.

It should be to give them enough understanding and practice that the new interface becomes a reliable part of their daily work.

When employees understand why the migration is happening and how the new workflow supports their responsibilities resistance becomes easier to manage. The ERP then has a much stronger chance of becoming the actual operating system of the business rather than another platform employees work around.