Why on-premises CRM users must decide before support ends
Organizations still running Dynamics 365 Customer Engagement (on-premises) 9.1 need to decide before the support date arrives, and the realistic choice is between Dynamics 365 online and a self-hosted open-source CRM. The self-hosted candidates covered here are SuiteCRM, EspoCRM and Odoo CRM. For many estates the deciding constraint is keeping customer data on infrastructure the organization controls, so the question is where the database, attachments and user access will live after the move. Confirm the exact end-of-support dates for your specific version and update level in Microsoft's lifecycle documentation, because this page does not state them and your dates may differ from general guidance.
Start the decision with an inventory of what the current estate does. List the entities and customizations your users depend on, the workflows and business process flows that move opportunities, the Outlook and Microsoft 365 links, the reports finance reads, and how users sign in, whether through Active Directory or another identity provider. Each item needs a counterpart either in Dynamics 365 online or in a self-hosted CRM where your team runs the servers, database and backups. Ask whether your data residency or contract terms require the database to stay in your own data center, because that answer narrows the options faster than any feature list. The hosting question decides more than the feature question does.
Work backward from the confirmed end-of-support date to set the migration window, and fix that window before you choose a platform. Freeze new customizations early, extract complete data sets from Dataverse, and run a test migration on a staging copy before anyone sets a cutover date. Plan for ongoing ownership too: patching, upgrades and backups move to your team or your implementation partner. In Odoo's case, its upgrade documentation says the upgrade service needs an Enterprise subscription for on-premise use, and the Community edition has no access to it, so confirm the edition and support terms before you commit to a suite. Check the Odoo upgrade documentation for the current requirements.
What staying on your own servers requires from a CRM
Keeping CRM data on your own servers moves hosting, sign-in, patching, backup and customization work from Microsoft to your team or implementation partner. The cards below set out the decisions each choice creates, using the supported versions and support windows for SuiteCRM 8, EspoCRM and Odoo.
Where data and files live
Self-hosting means you own the database, the uploaded documents and the email attachments, so the storage design is your decision. SuiteCRM 8 runs on Apache with MariaDB or MySQL, EspoCRM on Apache, Nginx or IIS with MySQL, MariaDB or PostgreSQL, and Odoo on PostgreSQL. Confirm where backups and file storage sit, who can reach them, and whether the location meets your residency rules. Dynamics 365 Customer Engagement on-premises already has this model, so check which storage was local to it.
Sign-in against your directory
Users need to sign in with the directory you already run, not a separate password. SuiteCRM 8 supports LDAP (AUTH_TYPE=ldap) and SAML (AUTH_TYPE=saml). EspoCRM supports OpenID Connect and LDAP, including Active Directory. Test single logout before cutover: the SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout, so signing out at the identity provider leaves the CRM session open. EspoCRM's own two-factor authentication is not compatible with OIDC, so plan MFA at the identity provider.
Supported runtime and database versions
Each platform publishes a narrow compatibility matrix, and your database and PHP versions must match it before you build the target. SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4 on Linux, Unix or macOS. EspoCRM requires PHP 8.3 to 8.5 and MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. Check these against your current server build before you choose a target.
Release and patch cadence
Self-hosting makes your team responsible for applying releases. SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes. Odoo SaaS versions ship every two to three months, and Odoo standard support covers three years after a major release, with security patches only during that window. Odoo 17.0 standard support ended in September 2026, so confirm which version you would deploy and its support end date. Assign an owner and a monthly patch slot before go-live.
Backup and restore ownership
No vendor backs up your CRM for you once it runs on your servers. Your team or partner owns database dumps, file copies, restore tests and retention. EspoCRM ships a command.sh utility for backups, restores and upgrades in its script-based install. Zoho's backup feature excludes email, documents and integration data, so check what a backup in any tool does not cover. Test a full restore on a separate instance before cutover, and record how long it takes.
Customizations that survive upgrades
Custom fields, workflows, scripts and integrations are where upgrades usually break. SuiteCRM migrations may remove non-core files under the public/legacy folder, so review every customization before a move. EspoCRM uses Formula Script in Entity Manager, API and workflow scripts, and official extensions such as the Advanced Pack should be checked against each release. Odoo Studio and custom modules are available only on the Custom plan. Keep customizations in version control and test every upgrade on a staging copy.
How to read the lifecycle dates for SuiteCRM, EspoCRM and Odoo
The first thing to know is that each candidate counts support differently, so a date that looks comparable on paper may not be. SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes with no new features or database changes. That makes routine patching predictable, but it also means you must schedule upgrades to keep pace. SuiteCRM 7.15 is the exception: it is an extended support release that receives security fixes until January 2028. No SuiteCRM 8 extended support release had been nominated when this was written, and SuiteCRM expects to name one by Q3 2027. Confirm that status on the SuiteCRM LTS page before you commit a long-term plan to SuiteCRM 8.
EspoCRM publishes major versions with fewer lifecycle commitments on its release history. The releases documented in the GitHub history include 10.0.0, released on July 2, 2026, and 10.0.10, released on October 14, 2026, following the previous major version, 9.0.0, released on January 20, 2025. Read those dates as release history, not as a support window. Ask EspoCRM in writing how long each major line receives security fixes, and whether a security-only track exists for self-hosted installations. For Odoo, the windows are more explicit. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and Odoo 17.0 standard support ended in September 2026. Extended support after that is limited to Odoo.sh for select versions and on-premise, and security patches are provided only during standard support. Odoo 18.0 standard support runs until September 2027 and 19.0 until September 2028.
Place these windows beside your Dynamics 365 Customer Engagement end-of-support date and ask three questions: how many months of supported operation each candidate gives after your planned cutover, whether that support includes security patches or only bug fixes, and what the upgrade path costs in staff time and any paid tier. For Odoo on-premise, remember that upgrades require an Enterprise subscription and the Community edition has no access to the upgrade service. Confirm every date on the vendor's own page on the day you plan, because lifecycle dates change between releases.
Which self-hosted open-source CRM fits a Dynamics 365 on-premises estate
This table compares SuiteCRM 8, EspoCRM and Odoo CRM on how each keeps customer data on your servers and where each one needs extra work from your team. Read each row against your current Customer Engagement customizations, identity setup and whether you need reporting and workflow out of the box. The main takeaway is that all three can stay on your infrastructure, but each has login, licensing or hosting limits you should confirm before choosing.
| Option | How it keeps data on your servers | Trade-offs |
|---|---|---|
| SuiteCRM 8 | Self-hosted on your Linux, Unix or macOS servers under AGPLv3, with an Angular frontend and Symfony backend. Login can use LDAP or SAML from your own directory. | SAML does not support IdP-initiated logout, so ending a session at the identity provider does not end the SuiteCRM session. Paid SuiteASSURED support from SuiteCRM Ltd is optional. |
| EspoCRM | Self-hosted under AGPL-3.0 on PHP with MySQL 8.0+, MariaDB 10.6+ or PostgreSQL 15+. Supports OIDC and LDAP, including Active Directory, and a REST API for integrations. | EspoCRM's own 2FA is not compatible with OIDC, so confirm how sign-in will be secured. Reports, BPM and workflows come from the Advanced Pack, an official add-on. |
| Odoo CRM | Community edition is self-hosted under LGPL-3.0 on Python and PostgreSQL. Enterprise source is not public and requires a subscription or partner access. | On-premise hosting requires the Custom plan, and the upgrade service needs Enterprise. Community users have no access to that upgrade service, so plan major upgrades yourself. |
Dynamics 365 online or a self-hosted CRM: which path fits which constraint
Some regulated organizations must keep customer records, contact data and attachments on servers they control. That requirement holds only if your team can name where each database table, file store and backup sits and who can reach it. Self-hosting meets it when the stack fits your infrastructure. SuiteCRM 8.10 lists PHP 8.2, 8.3 and 8.4, Apache 2.4 and MariaDB or MySQL on Linux, Unix or macOS, which your team can run in its own data center, cloud account or air-gapped network. EspoCRM runs on PHP with MySQL, MariaDB or PostgreSQL and ships an installation script for Ubuntu, Debian and Linux Mint that deploys a Docker stack with Nginx and MariaDB.
- Stack you can host: Check your operating system, PHP and database versions against the current SuiteCRM compatibility matrix before you size servers.
- Backups under your control: EspoCRM's command.sh utility covers backups, restores and upgrades, but retention periods and off-site copies remain your responsibility.
- Attachments and file storage: Confirm where uploaded files are written on your chosen platform and include that path in backup, encryption and access reviews.
- Odoo on-premise terms: On-premise Enterprise databases are activated with a subscription code, and the Community edition has no access to Odoo's upgrade service.
- Exit from the cloud: Extract Dynamics data and attachments into a staging instance first, so the cutover does not depend on the subscription still being active.
Before you commit, confirm with Microsoft whether the Dynamics 365 online license and data location you would keep meet your residency rule, because the facts available to this page do not describe that.
When the main pressure is budget, compare the cost of running a new platform with the cost of the current subscription, component by component. SuiteCRM and EspoCRM carry no software fee for self-hosting, so the recurring costs are servers, database administration, patching and the staff who run the system. The one-time costs are migration, field mapping, customization and user training. Dynamics 365 costs are per-user subscriptions and add-ons that Microsoft lists, so ask for a quote that shows the exact editions and add-ons you need. The result depends on your user count and on how much work your internal team can absorb.
- One-time work: Data migration, field mapping, testing on a staging instance and user training are paid once, although they can take a long time to complete.
- Recurring work: SuiteCRM minor 8.x releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes, so budget staff time for regular upgrades.
- Support options: SuiteCRM Ltd sells SuiteASSURED support, SuiteCRM Hosted, implementation, training and migration services, which you can compare with a fixed-scope engagement from an implementer.
- Hosted reference point: The EspoCRM pricing page lists EspoCRM Cloud at 15 US dollars per user per month on the Basic plan (minimum 3 users), a useful benchmark if you would rather not run servers.
- Quote structure: Ask every vendor, Microsoft included, for pricing that separates licenses, hosting, migration, customization and support.
Request renewal and reduction terms from Microsoft in writing before you set a cutover date, because those terms determine how long you must keep paying during the migration window.
If your organization runs Microsoft 365 and signs users in with Entra ID, the question is which sign-in flow and mail or calendar integrations carry over. SuiteCRM 8 supports LDAP and SAML, enabled through AUTH_TYPE set to ldap or saml. EspoCRM supports OpenID Connect since version 7.3, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. Odoo documents LDAP authentication, which needs its own review against your directory design. Each path requires a test in your own Entra tenant before cutover, with real user accounts from a pilot group.
- SAML for SuiteCRM 8: The SAML option uses the nbgrp onelogin-saml-bundle. Follow the SuiteCRM SAML configuration reference when you register the application in Entra.
- Logout gap: From 8.7.0, SuiteCRM does not support IdP-initiated logout or POST binding to the logout service, so signing out at Entra does not end the SuiteCRM session. Plan user guidance and session timeouts.
- OIDC for EspoCRM: Backchannel logout and a fallback login method are available, but EspoCRM's own two-factor authentication is not compatible with OIDC, so multi-factor enforcement must come from Entra.
- Outlook and Microsoft 365: EspoCRM lists an official Outlook extension among its add-ons. Confirm that it covers the mail and calendar behavior your users rely on today.
- Dynamics-side features: Copilot and Power Platform features are outside the facts available here, so list the ones your users depend on before you choose a target.
Confirm with Microsoft which Entra features and Dynamics 365 integrations your tenant uses today, because those dependencies decide how much rework the identity move requires.
How to plan the migration window before support runs out
This sequence turns an approaching support end date into a dated, tested cutover plan, with a staging copy, a complete data extract, validated records and a verified backup before the old servers are retired.
Confirm the version and support end date
Your team confirms the exact Dynamics 365 Customer Engagement build and its end-of-support date in writing with Microsoft or your licensing partner, and records which servers, databases and service accounts run it. An implementation partner would normally review that record and scope the migration window against the agreed date in writing. This step is done when the date, the version and the owner of the decision are recorded in a signed-off project charter. The window length depends on the agreed scope and is not fixed by this page.
Inventory entities, customizations and integrations
Your CRM administrators list every custom entity, field, form, view, business process flow, workflow, plug-in, report and integration that reads or writes CRM data, including Outlook, email tracking, SSO and any reporting connections. Your team also names the business owner for each item. A partner would typically review the inventory, classify each item as keep, rebuild or retire, and scope the rebuild work in writing. The step is complete when every item has a disposition and an owner.
Choose the target and build staging
Your leadership selects the destination, either Dynamics 365 online or a self-hosted open-source CRM such as SuiteCRM, EspoCRM or Odoo, based on the inventory and your hosting and data residency requirements. Your infrastructure team provisions a staging environment in your own network, and a partner would normally install, harden, configure authentication and document it under a written scope. The step is done when staging runs the chosen platform, the team can sign in with test accounts, and the build is documented.
Extract complete data from Dataverse
Your team extracts full table data from Dataverse using the routes described in the sibling export guidance, such as Excel exports for smaller views and Azure Synapse Link for complete table copies, and stores the extract in a controlled location with restricted access. A partner would normally scope the extraction, the file formats and the handling of attachments and audit data. The step is complete when row counts for each table are reconciled against the source and the extract is checksummed and archived.
Map and load test records
Your business analysts map source fields to target fields for accounts, contacts, opportunities, activities, products and any custom entities, and agree how lookups, owners and historical stage values translate. Your team loads a test set into staging, and a partner would normally write the import scripts or mappings and log each rejected record with its reason. The step is done when a defined sample of records matches the source on key fields and every rejection has a documented fix.
Run parallel validation with real users
Your sales and service users run their daily work in staging for a period agreed in the plan, covering quotes, pipeline updates, reporting and sign-in. Your team records defects, and a partner would normally triage them against the scope and retest fixes. The step is complete when users sign off on the critical workflows, open defects are resolved or accepted in writing, and the data reconciliation is repeated on the final extract.
Plan cutover and rollback
Your team writes a cutover runbook with the freeze time for edits in the source, the final extract, the load order, verification checks, user communication and the decision point for rollback. A partner would normally rehearse the runbook in staging and document the rollback path with its data implications. The step is done when a rehearsal completes within the agreed plan and the go or no-go criteria are approved by the business owner.
Verify backups and retire old servers
After cutover, your team confirms that a full backup of the old Dynamics 365 on-premises databases, files and configuration exists and that a test restore has succeeded, then keeps it under your retention policy. Only after that check does your infrastructure team decommission the old servers and revoke service accounts. A partner would normally document the archive location and the restore procedure. The step is complete when the restore test is recorded, access is removed and the decommissioning is signed off.
What auditors and regulators ask for when CRM data moves
A move off Dynamics 365 Customer Engagement on-premises leaves a trail that auditors and regulators will ask to see. The cards below list the records that connect the old system, the migration and the new self-hosted CRM. DeployOpen prepares the systems, controls and evidence, while independent auditors and certification bodies issue any audit report or attestation.
Data inventory and classification
Start with a written list of every entity, field, attachment and integration that holds customer or personal data in the on-premises Customer Engagement organization, including custom entities and reports. Record the classification of each dataset and the owner who approved it. Check that the inventory covers data outside the core sales tables, such as activity history, documents and exports already sitting in shared drives, because these often fall outside the migration scope and then surface in an audit.
Approved migration and rollback plan
Keep a signed migration plan that names the source and target systems, the cutover sequence, the decision makers and the conditions for proceeding. Pair it with a rollback plan that states who can trigger a return to the old system, what data written after cutover would need to be reconciled, and how long the on-premises environment stays available. Auditors look for evidence that the plan was approved before work began, not reconstructed afterward.
Staging tests and record reconciliation
Keep the results of test migrations run on a staging instance, including the record counts per entity from source and target, the exceptions found and how each was resolved. Reconciliation sign-offs show that nothing was silently dropped. The SuiteCRM migration guidance recommends staging tests and file and database backups before any production move, so record those steps with dates and the people who ran them.
Access control and sign-in configuration
Document how users, roles and teams map from Dynamics security roles to the new platform, and who approved each mapping. Record the sign-in method chosen, such as LDAP, SAML or OpenID Connect, along with its configuration settings, certificate ownership and the known limits of each option. For example, a SAML implementation that does not handle identity provider-initiated logout means the reader must note that logging out at the identity provider does not end the CRM session.
Backup and restore test records
Keep dated records of full backups, restores into a separate environment and the time each restore took, along with the results of checking restored data against the source counts. Backups of the new self-hosted system are your responsibility, unlike the Dynamics service model, so the restore test is the evidence that the backup works. Record who performed each test and what was recovered.
Change and patch log
Maintain a log of every configuration change, customization, security update and version upgrade applied after go-live, with the approver and the test evidence behind it. Each release should be traced to a change record. Confirm your upgrade cadence against the vendor's published release and support dates before you commit to it, because an unsupported version will weaken every later control you rely on.
Questions buyers ask about on-premises end of support
What drives the cost of moving off Dynamics 365 Customer Engagement on-premises?
The biggest drivers are the amount of Dynamics customization you carry forward, the number of integrations, the volume of data to clean and map, and the hosting environment you choose. Costs fall into a few components: software licenses (open-source downloads are free, but Odoo Enterprise and hosted plans carry fees), servers and database hosting in your own environment, migration and customization work, support contracts, and internal staff time. Your infrastructure provider is paid for hardware or virtual machines, a partner is paid for scoped work, and your staff are needed for business decisions and testing. If you compare against a hosted option, the EspoCRM pricing page lists per-user monthly rates for EspoCRM Cloud, but those rates do not include a self-hosted stack.
Which migration costs are one-time and which ones recur each year?
One-time costs cover scoping, data extraction, field mapping, building the migration, rebuilding workflows and reports, testing, cutover, documentation and user training. Recurring costs cover hosting, storage for backups, patching, upgrades, monitoring, any support subscription, and the staff time to run them. The recurring share grows with the upgrade cadence of the platform you choose. Odoo's standard and extended support documentation says standard support covers the first three years after a major release, with extended support limited, so plan upgrades on a fixed calendar. SuiteCRM 8 minor releases arrive roughly every eight weeks, so budget for regular patch windows.
How long does a CRM migration take, and what sets that length?
No supplied figure gives a duration for this migration, so ask for a timeline in the written scope rather than relying on a generic estimate. The length depends on data volume, the number of custom entities, workflows and business process flows, integrations with Outlook and identity systems, and how many users need training. Start from your Dynamics extended support end date, which you should confirm with Microsoft's lifecycle documentation, then work backward. The SuiteCRM migration documentation advises testing on a staging instance, so plan at least one full rehearsal before cutover. Odoo's upgrade guidance similarly recommends testing an upgraded copy before production.
What does the migration require from our own team?
Your team needs named business owners for accounts, opportunities, quotes and cases, who can confirm field mapping and sign off on test results. You also need someone who knows the existing Dynamics customizations, workflows and business process flows, because those rarely appear in a data export. IT must provide servers, DNS, certificates, backups and identity settings, and a test group must run through real sales scenarios. Review customizations carefully: the SuiteCRM migration documentation warns that the move may remove non-core files under the public/legacy folder. Identity options such as LDAP or SAML for SuiteCRM, or OpenID Connect for EspoCRM, need decisions from your identity team before go-live.
Can our IT team run this migration without an outside implementation partner?
Some teams can, if they already have database administration, PHP or Python, integration and identity skills, and enough time to run a staging rehearsal alongside daily work. The harder cases involve large Dynamics customization, many integrations, heavy data cleanup or evidence requirements for a compliance assessment. Before deciding, inventory the Dynamics components in use and ask whether the people who would do the work have run a comparable migration before. DeployOpen plans, implements, customizes, integrates, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, so you can split the work between your team and an outside partner in writing.
What should a written quote for this migration include?
A useful quote lists scope by object, workflow, report and integration, plus the source inventory of Dynamics components you are moving. It should name the target platform and version, the hosting environment, the data extraction method, the mapping rules and the testing plan, including staging rehearsals and acceptance criteria. Ask for the cutover plan, the backup and rollback steps, the training and documentation deliverables, the support period after go-live, and any ongoing support or retainer terms. Also request a list of assumptions and exclusions, the client actions the schedule depends on, a change-control process and payment milestones. DeployOpen does not publish a price list, and its fixed-scope quote follows from that written scope, agreed before work starts.
How DeployOpen plans a self-hosted CRM move from Dynamics 365 on-premises
DeployOpen plans the move off Dynamics 365 Customer Engagement on-premises as an implementation project inside your own infrastructure, not as a generic software swap. We start from your current 9.1 environment, your customizations and your user base, then agree in writing what the replacement must do before any build begins.
How we scope
- We inventory the 9.1 deployment, its customizations, plug-ins, integrations and reports against the written scope.
- We agree which entities, workflows, Outlook and SSO links, and user groups move, and which are retired.
- Engagements are fixed-scope, so deliverables, timelines and acceptance criteria are confirmed in writing before work starts.
How we build
- We install the chosen open-source CRM on your servers or cloud accounts, including database, web tier and backups.
- We configure authentication to your directory, such as LDAP or SAML, and test sign-in and sign-out behavior.
- We run test migrations on a staging copy, reconcile record counts and document every exception before cutover.
How we hand over
- We deliver runbooks for installation, backup, restore, upgrades and user administration in your own environment.
- We document data mappings, customizations and retained evidence so your auditors and compliance teams can review them.
- We walk your administrators through operation and confirm the handover checklist with you in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover is complete.
- We help you plan upgrades on the vendor's release cadence and test each one on staging before production.
- Ask us to confirm the support scope, response expectations and upgrade responsibilities in the quote before signing.
