Continuous ERP Updates: A Practical Governance Checklist for Odoo and Dynamics 365

Overview

ERP upgrade planning once fit comfortably into annual or twice-yearly calendars. IT teams could review a published release plan, identify major changes, schedule testing and prepare users around a predictable release window.

That model is changing.

Starting in September 2026, Microsoft will stop publishing its traditional Dynamics 365 and Power Platform Release Plans. New Dynamics 365, Power Platform and Dataverse capabilities will instead appear in Microsoft's AI at Work roadmap, which Microsoft describes as an always-on destination for discovering upcoming capabilities, monitoring rollout progress and planning adoption across its business applications and AI portfolio.

Odoo follows a different release model but creates a similar governance challenge. Odoo releases major versions, while Odoo Online also receives intermediary SaaS versions every two to three months. Odoo.sh and on-premise environments remain tied to major releases rather than those intermediary Online versions. You can review the Odoo version support policy to understand how these release paths differ.

For IT managers, the lesson is increasingly clear: ERP change governance cannot be a project performed only when a major upgrade begins. It needs to become a recurring operating process.

The practical response is a monthly governance cycle covering releases, custom modules, integrations, permissions, automated testing, user adoption and business continuity.

What Changes for Dynamics 365 in September 2026?

Microsoft's 2026 Release Wave 1 covers functionality releasing between April and September 2026. It is also the final release-plan cycle before the old publication model is retired.

From September 2026, upcoming Dynamics 365, Power Platform and Dataverse features will move into the AI at Work roadmap.

This matters because IT departments that previously organized planning around two large release-plan documents will need to monitor a continuously updated roadmap instead.

The change is primarily about how Microsoft communicates and exposes upcoming capabilities.

It should not be interpreted as Microsoft abandoning structured deployment management or suddenly deploying every new capability immediately.

Microsoft's current service-update guidance still describes two major Dynamics 365 update periods around April and October. It also documents weekly minor service updates and planned or unplanned maintenance.

The governance change is therefore:

From periodic roadmap review to continuous roadmap monitoring.

That distinction matters when building an update policy.

Continuous Roadmap Does Not Mean Continuous Production Activation

ERP leaders should separate three concepts:

• Roadmap disclosure
• Software deployment
• Feature activation

A feature appearing on Microsoft's continuously updated roadmap does not automatically mean every tenant must immediately redesign its process.

Microsoft notes that features affecting user experience may remain disabled by default, while customers can use early-access options to test upcoming release-wave capabilities before general availability.

This means IT governance still has room for:

• Impact assessment.

• Sandbox testing.

• User acceptance testing.

• Security review.

• Process documentation.

• Training.

• Controlled activation.

The difference is that administrators can no longer depend solely on reviewing one large roadmap twice per year.

A strong Dynamics 365 implementation and update strategy should connect roadmap items with business processes, security roles, integrations and user training. This prevents the common mistake of treating every announced feature as an immediate production requirement.

How Odoo's Update Model Differs

Odoo's release structure is more deployment-dependent.

According to Odoo's standard and extended support documentation, major versions currently receive standard support for three years, including helpdesk support, bug fixes and security updates. Odoo also releases intermediary SaaS versions approximately every two to three months, but those releases are available only on Odoo Online.

Odoo.sh and on-premise environments use major Odoo releases instead.

This creates different governance situations.

Odoo Online also does not support custom Python modules or Odoo Apps Store modules, which reduces one major source of upgrade complexity. Odoo's Odoo Online documentation explains the limitations and operating model of the hosted platform.

Odoo.sh and on-premise databases can contain extensive custom code, which means their governance needs to focus much more heavily on technical compatibility.

For organizations evaluating an Odoo upgrade roadmap, the hosting model should be documented before any technical assessment begins. The same upgrade plan cannot be applied equally to Odoo Online, Odoo.sh and on-premise deployments.

Why Annual Upgrade Meetings Are No Longer Enough

An ERP environment changes even when the company does not intentionally begin a major upgrade project.

Dependencies change around the ERP.

Payment providers modify APIs. Shipping companies introduce new authentication methods. Employees change roles. Custom modules receive new commits. Browsers evolve, while external platforms change webhook structures.

At the same time, SaaS ERP vendors continuously improve their products.

A governance process that reviews these issues once per year may discover twelve months of accumulated risk at the same time.

Monthly governance allows smaller issues to be identified while they are still manageable.

The objective is not to install every available update each month. It is to know what changed, what may change and whether the ERP remains ready for the next change.

This approach also improves budgeting. Instead of discovering a large number of unsupported modules, outdated integrations or undocumented workflows during an emergency upgrade, the IT team can identify them gradually and assign ownership before they become business-critical risks.

Build a Monthly ERP Governance Checklist

A useful monthly review should be short enough to repeat but detailed enough to identify material risk.

This checklist should become part of normal ERP operations rather than being created again for every upgrade.

A practical governance meeting can be completed in sixty to ninety minutes if the information is prepared in advance. The meeting should focus on exceptions, decisions and ownership rather than reading release notes line by line.

1. Review the Vendor Roadmap Every Month

Dynamics 365 administrators should now make roadmap review a recurring responsibility.

From September 2026, the AI at Work roadmap becomes the primary destination for upcoming Dynamics 365, Power Platform and Dataverse capabilities. Microsoft says customers will be able to view upcoming features and track rollout progress across products from this unified roadmap.

The monthly review should classify relevant features as:

• No impact.

• Monitor.

• Test required.

• Training required.

• Configuration change required.

• Integration risk.

• Security impact.

• Strategic opportunity.

Odoo administrators should perform a similar review around major releases, intermediary Odoo Online versions and support timelines.

The purpose is not merely learning what is new. It is turning vendor change into an internal decision.

For each relevant roadmap item, record the affected module, business owner, technical owner, expected availability, testing requirement and recommended action. A simple roadmap register can prevent important changes from being lost in email threads or informal conversations.

2. Maintain a Custom Module Inventory

Customization is one of the biggest differences between standard SaaS environments and heavily extended ERP deployments.

For Odoo.sh or on-premise systems, the organization should maintain a current list containing:

• Module name.

• Business owner.

• Technical owner.

• Odoo dependencies.

• Third-party dependencies.

• Last modification date.

• Automated test coverage.

• Upgrade status.

• Criticality.

• Data migration requirements.

• Current production version.

Every month, developers should review whether newly introduced customizations increase dependency risk.

Odoo's customized-database upgrade guidance recommends making custom modules work on the target version and then testing them against the upgraded production data. Data migration scripts may also be required when fields, models or XML identifiers change.

This work becomes significantly easier when the module inventory is already current before the upgrade begins.

A useful classification is:

• Critical: The business cannot operate without it.

• Important: A workaround exists but productivity would be affected.

• Optional: The module improves convenience but is not essential.

• Retire: The module is no longer used or duplicates standard functionality.

This classification helps management decide where testing and upgrade budget should be concentrated.

3. Monitor Integrations Before They Fail

ERP upgrades commonly expose integration weaknesses that have existed for months.

An integration register should identify every external dependency, such as:

• eCommerce platforms.

• Logistics providers.

• Payment gateways.

• Banks.

• CRM systems.

• Data warehouses.

• Power Platform applications.

• Custom APIs.

• Webhooks.

• Tax and compliance services.

• Document-signing platforms.

The monthly check should review API errors, failed synchronizations, expired certificates, OAuth credentials, changed payloads and unusually growing queues.

The organization should also identify which ERP release or external API versions the connector currently supports.

BrowseInfo's Odoo upgrade guidance recommends revalidating authentication, tokens, webhooks, payloads, scheduled synchronization and error handling when custom integrations are moved across Odoo versions.

Do not wait for a major upgrade to discover that a business-critical integration has no current owner.

Every integration should have a documented failure procedure. The procedure should explain whether transactions can be safely retried, how duplicates are detected, who contacts the external provider and how the business operates if synchronization is unavailable for several hours.

4. Review Permissions as Part of Update Governance

Software changes can introduce new functions, objects, screens and permissions.

Employees also move between departments continuously.

A monthly ERP security review should therefore examine:

• New users.

• Departed employees.

• Department transfers.

• Administrator access.

• High-privilege roles.

• Integration users.

• Temporary access.

• Newly introduced modules.

• Security groups changed during development.

• Shared accounts.

• Inactive accounts.

• External user access.

Permission testing is especially important after an upgrade.

BrowseInfo's post-upgrade testing framework identifies user permissions, access control lists and record rules as high-priority validation areas because migration can affect how users interact with business data.

A functional upgrade is not successful if users can suddenly access records they should not see.

The monthly review should also confirm segregation of duties. For example, the same user should not automatically receive unrestricted rights to create vendors, approve purchase orders and process payments unless the business has formally accepted that risk.

5. Maintain a Permanent Regression Test Suite

Testing should not begin when a release date is announced. The organization should maintain a permanent list of critical business scenarios.

For example:

• Create lead and quotation.

• Confirm sales order.

• Reserve inventory.

• Complete delivery.

• Create customer invoice.

• Register payment.

• Create purchase order.

• Receive stock.

• Process vendor bill.

• Complete manufacturing order.

• Run key financial reports.

• Process returns and credit notes.

• Verify tax calculations.

• Confirm approval workflows.

• Export data to connected systems.

Custom workflows should be added to the same suite.

Odoo.sh provides Development branches where demo databases are created and unit tests run automatically. Staging builds use fresh copies of production data so teams can validate changes against realistic records. The Odoo.sh builds documentation explains how these environments support development and testing.

Microsoft similarly recommends opting into early-access updates so organizations can test upcoming Dynamics capabilities before general availability.

Testing should therefore be continuous even when production deployment remains controlled.

A regression suite should include expected results, test data, responsible testers and evidence requirements. Without these details, teams may claim that testing was completed even though important scenarios were checked only informally.

6. Validate Automations and Scheduled Processes

Automations frequently fail silently. An ERP may appear healthy while scheduled imports, notifications, recurring invoices or synchronization jobs have stopped running.

The monthly review should inspect:

• Scheduled actions.

• Workflow automation.

• Background queues.

• Failed emails.

• Recurring billing.

• Data synchronization.

• Power Automate flows.

• Webhooks.

• Batch jobs.

• Approval reminders.

• Automated reports.

• Data-cleanup routines.

Teams should identify both outright failures and abnormal changes, such as a job that historically completes in five minutes now requiring thirty.

Automation monitoring is particularly important after releases because underlying models or dependencies may have changed even when the user interface still appears normal.

For each critical automation, document the expected frequency, normal completion time, failure notification, business owner and recovery procedure. This turns automation monitoring from a technical task into a measurable operational control.

7. Verify Backup and Rollback Readiness

Business continuity requires more than successful testing. IT must know how to recover when testing fails to identify a production issue.

Odoo.sh automatically backs up production databases and keeps daily, weekly and monthly backups. When a production code update fails to load correctly, Odoo.sh can reuse the previous successful revision and roll back the database to its earlier state. The Odoo.sh branches documentation provides additional information about this process.

This capability is valuable, but organizations should still verify backup availability and recovery responsibility.

Monthly questions should include:

• Was the latest backup successful?

• Does it include the filestore?

• Who can restore it?

• Has recovery ever been tested?

• What is the acceptable recovery time?

• What is the acceptable data-loss window?

• What happens if an external integration duplicated transactions before rollback?

• Are backup credentials protected?

• Is the recovery procedure documented outside the ERP?

A rollback plan is part of the release plan.

For on-premise environments, the organization should also test infrastructure recovery, database restoration, file storage recovery, DNS changes, certificates and integration reconnection. A database backup alone may not be enough to restore the complete operating environment.

8. Monitor User Adoption After Every Change

Technically successful updates can still damage productivity.

A redesigned screen may require more clicks. A new mandatory field may confuse employees, while a useful new feature may remain unused because nobody knows it exists.

Monthly governance should therefore review:

• Support-ticket volume.

• Repeated user questions.

• Workarounds.

• Spreadsheet usage.

• Data-entry errors.

• Feature adoption.

• Training requests.

• Process delays.

• Manual corrections.

• Complaints from key departments.

A small increase in support requests immediately after an update may be expected.

A continuing pattern usually indicates a process, interface or training problem.

ERP governance should therefore include both technical stability and human adoption.

User feedback should be categorized rather than treated as a general complaint. Some issues require training, some require configuration, some require a product change and others indicate that the original business process was not clearly defined.

9. Maintain a Change Register

Every production change should leave a record.

The register should capture:

• Change description.

• Date.

• Vendor or internal source.

• Business impact.

• Systems affected.

• Test evidence.

• Owner.

• Rollback method.

• Training required.

• Production outcome.

• Related incident or ticket.

• Approval status.

This becomes especially useful in a continuous roadmap model because the organization may process dozens of small changes rather than one obvious upgrade project.

Six months later, IT should still be able to explain why a feature was activated and who validated it.

The change register should also identify emergency changes. Emergency work may be necessary, but it should receive a retrospective review to confirm that testing, documentation and approval gaps are corrected afterward.

Dynamics 365 Requires a New Planning Habit

The September 2026 change means Dynamics administrators should move away from the mindset that roadmap analysis happens primarily around two release-plan publications.

Microsoft's AI at Work roadmap is intended to remain continuously updated.

At the same time, operational deployment governance still needs to account for service-update cadence. Microsoft currently documents weekly minor service updates, while major feature releases continue around the April and October periods.

The governance model therefore becomes:

Monitor continuously but activate deliberately.

That is more accurate than assuming Dynamics has simply become a continuous-release ERP with no planned testing windows.

Dynamics 365 teams should maintain a release calendar that includes roadmap review, early-access testing, sandbox validation, user acceptance testing, production deployment, post-release monitoring and business-owner sign-off.

The calendar should also identify blackout periods. Financial close, annual inventory counts, peak sales seasons and regulatory deadlines may not be suitable times for optional configuration changes.

Odoo Requires Different Governance by Hosting Model

Odoo governance should begin by identifying where the database runs.

Odoo Online organizations should focus heavily on functional change monitoring, permissions, user training and business-process regression because custom Python modules are not supported.

Odoo.sh customers need stronger code governance because custom modules can be maintained in Git, while Development and Staging environments provide testing layers. The Odoo.sh development documentation explains how branches can support controlled development and deployment.

On-premise organizations carry even more responsibility for infrastructure, deployment, backups and version planning.

Odoo's support model also matters. Major releases receive three years of standard support, while intermediary SaaS releases are Online-only.

IT managers should therefore keep the current version and support deadline visible on the governance dashboard.

For Odoo.sh and on-premise deployments, the upgrade plan should also include:

• Repository health.

• Branch strategy.

• Module ownership.

• Python compatibility.

• Database size.

• Filestore size.

• Migration scripts.

• Third-party module availability.

• Staging refresh procedures.

• Production cutover timing.

• Rollback limitations.

Use Quarterly Deep Reviews Alongside Monthly Checks

Monthly governance should identify drift.

Quarterly reviews should examine broader architecture.

A quarterly review can include:

• Customization growth.

• Technical debt.

• Unsupported modules.

• Vendor roadmap implications.

• Integration architecture.

• ERP performance.

• Security posture.

• Upcoming end-of-support dates.

• Major training requirements.

• Upgrade budget.

• Data quality.

• Reporting dependencies.

• Disaster-recovery readiness.

This creates two levels of governance.

Monthly: Is the environment healthy?

Quarterly: Is the architecture still moving in the right direction?

Major upgrades then become planned outcomes of ongoing governance rather than emergency projects.

Quarterly reviews should include business leadership, not only IT. Finance, sales, operations, supply chain and human resources may experience different effects from the same ERP change. Their input helps ensure that technical priorities remain connected to business priorities.

How BrowseInfo Can Help With Continuous Odoo Governance

BrowseInfo's current Odoo upgrade roadmap guidance covers assessment, custom modules, integrations, data migration, testing, cutover, training and post-go-live validation. It emphasizes that upgrade complexity increases when environments contain old custom code, third-party modules and multiple external integrations.

A continuous Odoo governance engagement can include:

• Version and support review.

• Custom module inventory.

• Upgrade-readiness analysis.

• Third-party module assessment.

• Integration monitoring.

• Automated test development.

• Odoo.sh staging validation.

• Permission testing.

• Performance review.

• Upgrade rehearsals.

• User acceptance testing.

• Cutover and rollback planning.

• Post-upgrade support.

• Documentation and knowledge transfer.

The objective should be to make each future Odoo upgrade predictable rather than treating every new major release as a separate technical emergency.

A partner can also help identify where standard Odoo functionality can replace custom code. Reducing unnecessary customization lowers future upgrade effort, simplifies testing and makes the ERP easier for internal teams to maintain.

Common Continuous ERP Governance Mistakes

One mistake is assuming SaaS removes upgrade responsibility. SaaS can reduce infrastructure work, but the business still owns integrations, user adoption, access policies and process validation.

Another is reviewing release notes without translating them into internal impact.

Other common mistakes include:

• No owner for roadmap monitoring.

• No inventory of custom modules.

• Testing only major workflows.

• Ignoring API dependencies.

• Excessive administrator access.

• No rollback rehearsal.

• Training users only after deployment.

• Keeping unsupported custom modules.

• Treating every new feature as mandatory.

• Failing to document emergency changes.

• Ignoring data quality.

• Not involving business owners.

• Using production as the first testing environment.

• Assuming a successful deployment means a successful adoption.

Continuous governance should create awareness and control, not pressure to deploy everything immediately.

Frequently Asked Questions

1. Is Microsoft ending Dynamics 365 release planning?

Microsoft is retiring the traditional Release Plans starting in September 2026. Upcoming Dynamics 365, Power Platform and Dataverse capabilities will instead be published through the continuously updated AI at Work roadmap. Existing release plans remain available for historical reference. You can review Microsoft's Dynamics 365 release-plan information for the current transition details.

2. Does this mean Dynamics 365 will no longer have release waves?

The roadmap-publication model is changing, but Microsoft's current service-update guidance still describes major update periods around April and October along with weekly minor service updates. IT teams should distinguish roadmap disclosure from deployment cadence.

3. How frequently does Odoo Online receive new versions?

Odoo states that intermediary Online or SaaS versions are generally released every two to three months. These versions are available only on Odoo Online. The Odoo support policy explains the difference between major releases and intermediary SaaS versions.

4. Do Odoo.sh databases receive the same intermediary SaaS versions?

No. Odoo's intermediary Online versions are not available for Odoo.sh or on-premise installations. Those environments use major Odoo versions.

5. What should an ERP team check every month?

At minimum, review vendor roadmaps, custom modules, integrations, user permissions, automated tests, scheduled jobs, backups, performance, user adoption and the internal change register.

6. Should every ERP update be installed immediately?

No. New capabilities should be assessed for business impact, security, integration dependencies and user changes, then tested appropriately before controlled activation or production rollout.

7. How does Odoo.sh help with update testing?

Odoo.sh Development branches can run unit tests, while Staging branches use neutralized copies of production data for realistic validation. Production builds can revert to a previous successful revision when an update fails to load. The Odoo.sh builds guide provides more detail.

8. Why should user adoption be part of ERP update governance?

A technically successful update can still reduce productivity if users do not understand new screens or processes. Monitoring support requests, errors, workarounds and feature adoption helps identify problems that technical testing alone cannot reveal.

Conclusion

ERP update management is shifting from occasional project planning toward continuous governance.

For Dynamics 365 customers, that shift becomes especially visible in September 2026, when Microsoft stops publishing traditional Release Plans and moves Dynamics 365, Power Platform and Dataverse capabilities into the continuously updated AI at Work roadmap.

That does not mean IT teams should activate every capability continuously. It means they must continuously understand what is coming.

Odoo presents a different but related challenge. Odoo Online receives intermediary SaaS releases every few months, while Odoo.sh and on-premise environments follow major-version upgrade paths. Custom modules can make those major upgrades significantly more complex.

The practical response for both platforms is the same governance discipline.

Review vendor changes every month. Maintain a current customization inventory. Test integrations before they break. Review permissions. Keep critical regression tests ready. Validate backups, monitor user adoption and document every production change.

Then use quarterly reviews for deeper architectural decisions.

When roadmap monitoring, customization governance, integration testing, security, regression testing, rollback planning and user adoption become continuous responsibilities, ERP upgrades stop being isolated high-risk events.

They become a normal part of operating a business-critical platform.