Dynamics 365 Sales vs EspoCRM: which fits your sales team
If your renewal notice, a per-user price change or a data residency rule has forced the question, EspoCRM usually fits a mid-sized sales team that wants a self-hosted CRM with a focused feature set, while Dynamics 365 Sales usually fits an organization already standardized on Microsoft 365, Dataverse and the Power Platform. EspoCRM covers accounts, contacts, leads, opportunities, reports and workflows without a Microsoft stack behind it, so it suits teams whose sales process is mostly CRM-native. The Advanced Pack, which provides Business Process Management and workflows, is included in all EspoCRM Cloud plans, but for self-hosted installs you should confirm how it is licensed for your edition before you plan the build.
Three questions usually decide the outcome. First, how much Dataverse and Power Platform your business already uses: if Power Automate flows, model-driven apps or Dynamics finance data depend on Dataverse tables, moving to EspoCRM means rebuilding those links yourself, and that work belongs in the cost model. Second, whether customer data must stay on your own servers: EspoCRM runs on your PHP stack with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, so residency is in your hands, but backups, patching and TLS are too. Third, who will run the platform. Ask who owns the server, the cron jobs EspoCRM needs for background work, upgrades and restores, and whether that team has time for them. Before you commit, check the Outlook and sign-in requirements in writing. EspoCRM supports OpenID Connect sign-in with Entra ID, but its own two-factor authentication does not work with OIDC, so confirm where MFA is enforced. Also confirm which Outlook and Microsoft 365 integrations you need, because the official Outlook extension is a separate item to test rather than a given. A short pilot with a few real opportunities, your approval rules and your mailbox sync will show whether EspoCRM fits before you size the rollout.
Which option fits which sales team situation
This table matches common sales team situations to the platform that usually fits best and explains the condition that makes each advantage matter. Read each row against your own licensing, hosting, admin capacity and reporting needs, because the same feature can be decisive for one team and irrelevant for another.
| Team situation | Better fit | Reason and the condition that matters |
|---|---|---|
| Microsoft 365 and Power Platform shop with Outlook as the daily sales tool | Dynamics 365 Sales | Native Outlook, Teams and Power Platform integration matters most when the business already runs on Entra ID and Power Automate. Confirm which Microsoft 365 and Dynamics licenses you hold before assuming the integration is included. |
| Team that must keep customer data on its own servers for residency or sovereignty reasons | EspoCRM | Self-hosting puts the database, attachments and backups inside your boundary. This advantage applies only if your hosting team can run PHP, the database and the scheduled jobs. |
| Small admin bench with no dedicated CRM developer | Dynamics 365 Sales | Microsoft handles platform upgrades and the Dataverse runtime. EspoCRM moves those tasks to your team, so this fit holds only if the bench can own patching, backups and upgrades. |
| Team that wants no-code entity fields, workflows and BPM without a vendor add-on | EspoCRM | Entity Manager, Formula Script and the Advanced Pack cover fields, workflows and BPM. This matters when you want those features in every cloud or self-hosted plan. Confirm the Advanced Pack terms for your deployment model. |
| Organization that needs deep Dataverse-based reporting, Copilot or Power BI on live sales data | Dynamics 365 Sales | Copilot and Dataverse analytics depend on the Microsoft platform. EspoCRM provides reports, but you would build any cross-system analytics yourself. Confirm the Copilot and Power BI licensing you need. |
| Single sign-on through an existing identity provider for all users | EspoCRM | EspoCRM supports OpenID Connect sign-in with Entra ID as one option, including group-to-team mapping. Confirm that your tenant configuration and the 2FA trade-off meet your identity policy before you commit. |
| Team with a custom application that calls the CRM through an API | Either, depending on skills | EspoCRM's REST API uses API key or HMAC authentication with role-based API users. Dynamics exposes Dataverse APIs. Choose on the team's existing integration skills and the authentication model your security team approves. |
What Dataverse does that EspoCRM leaves to you
Dynamics 365 Sales inherits platform services from Dataverse, so most customers never build them. On EspoCRM, the application covers the CRM layer, and your team owns access design, change control, change history, operations and the identity lifecycle.
Security roles and record access
Dataverse security roles define what each user can create, read and change, including access tied to record ownership and business units. EspoCRM provides roles, teams and API users with role-based permissions, but deciding who sees which accounts, opportunities and fields is your design work. Build the permission matrix before migration, then test it with sample accounts for each region, sales manager and support user. Owner: the CRM administrator, with a security reviewer signing off.
Solution packaging and promotion
Dynamics 365 solutions bundle customizations so they move from development to test and production in a controlled way. EspoCRM customizations live in the Entity Manager and in formula scripts on the running instance, so your team must decide how changes are promoted. Keep a staging instance and version control for formula scripts and configuration exports, and confirm in the EspoCRM documentation which export formats exist before you depend on them. Owner: the platform engineering team, with the CRM administrator.
Auditing and change history
Dataverse can record changes to tables and fields, which compliance reviewers often request when they ask who changed a deal value or an account owner. Confirm what change history EspoCRM keeps natively for entities, fields and API calls, and whether it is retained long enough for your review cycle. Plan an external log of administrative actions if the native history does not meet your requirement. Owner: the compliance lead, with the security team setting log retention.
Backup, restore and upgrades
On Dataverse, Microsoft runs the hosting layer as part of the service. With EspoCRM, the installation script deploys a Docker-based stack with Nginx and MariaDB and provides a command.sh utility for backups, restores and upgrades. Store backups off the server and test a restore before go-live, and run each upgrade in a planned change window. Owner: the platform team, with one named person accountable for restore tests.
Background jobs and scheduling
EspoCRM needs cron or a scheduled task to run background jobs, and without it queued work such as workflow actions and email processing can stall without an obvious error on screen. Dataverse handles its own platform processing. Check that the scheduler runs under the web service account, that failures reach an alert channel, and that workflow timing is tested under real volume. Owner: the system administrator who runs the EspoCRM host.
Identity lifecycle and sign-in
Dynamics 365 users sign in through Microsoft Entra ID as part of the Microsoft 365 estate. EspoCRM supports OpenID Connect sign-in with optional user creation on first login and mapping of identity provider groups to teams, plus backchannel logout. Its own two-factor authentication is not compatible with OIDC, so multi-factor sign-in must come from the identity provider. Define how joiners, movers and leavers are handled and who approves group changes. Owner: the identity team.
How capabilities compare for entity customization, workflows and reporting
This table maps the customization, workflow, reporting, scripting, Microsoft 365, API and data movement features that mid-sized sales teams usually depend on. Read each row against your current Dynamics 365 Sales license and the EspoCRM release you plan to deploy, because add-on packaging and feature sets change between versions. Where EspoCRM relies on an official extension, the row says so, so you can plan for that extension during scoping.
| Capability | EspoCRM | Dynamics 365 Sales |
|---|---|---|
| Entity and field customization | Admins add fields, entities and layouts in the Entity Manager without writing code. | Tables, columns and forms are customized in the platform tools; confirm which changes need a developer. |
| Workflows and business process | Workflows and BPM come from the official Advanced Pack, included in all EspoCRM Cloud plans. | Business process flows and automation are platform features; confirm which flows your license covers. |
| Reports and dashboards | Reports come from the Advanced Pack; confirm it is installed and licensed on your self-hosted instance. | Built-in reporting and dashboards; confirm whether the analytics you need require additional licensed tools. |
| Before-save logic | Formula Script runs in before-save scripts, API before-save scripts, workflows and BPM. | Server-side logic is often built as plug-ins or cloud flows; inventory it before cutover to map each rule. |
| Outlook and Microsoft 365 | An official Outlook extension is available; confirm its supported Outlook and Microsoft 365 versions. | Native Outlook and Microsoft 365 integration; confirm which client and server features your users rely on. |
| API access | REST API with API key, HMAC and basic authentication through dedicated API users; HMAC is the most secure method. | Dataverse Web API; confirm request limits and service protection rules in your current license. |
| Import and export | Import is documented; confirm record volumes, duplicate handling and file formats in the current docs. | Views export to Excel and bulk tools support larger extracts; confirm the methods and limits in your tenant. |
| Extensions beyond the official set | Integrations outside the official extensions are built and maintained by your team or a partner. | Marketplace apps and custom code extend the platform; confirm the license terms for each one. |
Where customer data lives and who controls it
Dynamics 365 Sales keeps records in Microsoft's cloud tenant under Microsoft's operating model, while EspoCRM can run in EspoCRM Cloud or on servers you control. The cards below cover the decisions that follow from that choice: where data sits, how people sign in, how API clients authenticate, and what evidence you can hand to an auditor.
Choosing where the data sits
Dynamics 365 Sales runs on Microsoft's cloud, so data residency and tenant location follow your Microsoft agreement. EspoCRM gives you three options: EspoCRM Cloud, a hosted instance you rent, or a self-hosted stack on your own servers or in your own cloud account. Self-hosting matters most when contact data is subject to residency rules or when you must show that no third party holds a copy. Ask the EspoCRM vendor where EspoCRM Cloud stores data, and confirm the region and backup location in writing before you choose it.
Hosting responsibility and upkeep
On a self-hosted EspoCRM, you own the PHP runtime, the database (MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15), the web server, TLS certificates and the cron job that runs background tasks. Dynamics 365 Sales moves most of that operating work to Microsoft. Decide who patches the operating system and database, who restores from backup, and who watches the cron job, because a missed background job can stall workflows without an obvious error.
Sign-in with Entra ID and Active Directory
EspoCRM supports OpenID Connect sign-in, so Microsoft Entra ID can authenticate users. The integration can create users on first login, map identity provider groups to EspoCRM teams, and keep a fallback login method. EspoCRM's own two-factor authentication does not work with OIDC, so enforce MFA in Entra ID instead. For Active Directory accounts without OIDC, EspoCRM also documents LDAP authentication. Test the fallback login and the group-to-team mapping before you remove any local administrator access.
API authentication choices
Dynamics 365 Sales exposes Dataverse Web API access through Entra ID app registrations. EspoCRM uses dedicated API users with role-based permissions and offers API key, HMAC and basic authentication. The documentation describes HMAC as the most secure option and basic authentication as not recommended. Choose HMAC for integrations that write customer data, give each integration its own API user with the smallest role that works, and rotate keys when a connected system changes hands.
Access control inside the application
Application-level permissions decide who sees accounts, opportunities and attachments. Dynamics 365 Sales uses security roles, teams and business units in Dataverse. EspoCRM uses roles, teams and ownership settings, and its formula scripts can run before saves, so a poorly reviewed script can change records that a user cannot normally edit. Review roles and scripts together, test with a non-administrator account, and record who approved each permission change.
Compliance evidence and what DeployOpen prepares
A regulator or auditor asks for evidence of access reviews, backups, change records and logs, not for a product name. Microsoft publishes compliance documentation for its cloud services, and a self-hosted EspoCRM leaves that evidence to your team. DeployOpen can plan, configure and document the controls, collect the evidence and prepare your team for assessment. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm the scope with them early.
What drives the cost on each side
The Dynamics 365 side is mostly recurring. Each named user carries a per-user license from the Dynamics 365 Sales edition you choose, and the Advanced Pack equivalent, Power Platform licenses for custom apps and flows, and Copilot usage are priced separately as Microsoft lists them. Before comparing numbers, ask your Microsoft partner or account team to write out which edition covers Business Process Flows, Outlook and Teams integration, and Copilot, and which of those need a separate license for every user or only for the people who build or run automations. Also confirm your Entra ID tier, since sign-in and conditional access depend on it. These line items, not the headline seat price, usually decide the total.
On the EspoCRM side, the software costs nothing to download and self-host under AGPL-3.0. For a comparison point, EspoCRM Cloud is listed at 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), according to the EspoCRM pricing page, and the Advanced Pack is included in those cloud plans. Self-hosting replaces that subscription with recurring costs you carry: servers, the database, backups, monitoring, and upgrades. Those recur. Migration, Entity Manager and Formula Script configuration, OIDC setup with Entra ID, and any extension work are largely one-time, though the people maintaining them are an ongoing cost.
Cost moves most with the number of people who must be trained and supported, the amount of workflow you rebuild, and the size of the data you migrate. Ask any implementation partner for a fixed-scope quote that separates one-time work (data mapping, migration, Formula Script rules, OIDC and backup testing) from recurring work (hosting, patching, upgrades, backups, support hours). Ask for a named staff estimate, the assumed user count, which EspoCRM version is targeted, and what happens when the next major release arrives. Ask too for the cost of restore testing, since backups are only part of the cost if restores are proven. Compare both sides over the same user count and the same number of years, and include the exit cost of Dynamics 365 data extraction in the Dataverse side of the ledger.
What running EspoCRM takes: cloud plan or self-hosted stack
EspoCRM Cloud is the vendor-hosted option. You pay per user per month on the plans listed on the EspoCRM pricing page, and the vendor operates the application, database, backups and upgrades under its own terms. The Advanced Pack is included in every cloud plan, so reports, Business Process Management and workflows are not a separate purchase.
- Plan and minimums: Basic is listed at 15 US dollars per user per month with a minimum of 3 users, Enterprise at 25 dollars with a minimum of 5 users, and Ultimate at 69 dollars with a minimum of 10 users.
- Hosting location: Ask which regions are available, where your tenant runs, and whether that meets your residency and sub-processor rules.
- Backups and restores: Confirm backup frequency, retention, restore testing and whether you can take your own full exports at any time.
- Release timing: Ask how and when the vendor applies releases in the 10.0 line and whether you can defer an upgrade that affects your customizations.
- Identity and extensions: Confirm which sign-in methods are available on your plan and which official extensions the vendor enables for you.
Confirm these points in writing against the plan you choose, because the vendor contract, not your internal runbook, sets them.
The installation script is the documented starting point for self-hosting on one Linux host. The installation docs describe a script for Ubuntu, Debian and Linux Mint that deploys a Docker-based stack with Nginx and MariaDB, with optional Let's Encrypt certificates. A command.sh utility handles backups, restores and upgrades, so the team's work centers on operating that host.
- Supported hosts: The docs name Ubuntu, Debian and Linux Mint. If your standard image is different, plan a test build before you commit.
- Containers and host upkeep: Nginx, MariaDB and EspoCRM run in Docker, so your team owns the Docker engine version, host OS patches and container image updates.
- Off-host backups: Use
command.shto create backups, then copy the archives to a second location, because a backup on the same disk does not protect against losing the host. - Restore testing: Restore each backup to a separate host on a schedule and before every upgrade. The script handles the mechanics, not your change window or rollback decision.
- Certificates: Let's Encrypt is optional. If outbound validation is blocked in your network, plan an internal certificate authority and renewal process.
Before you deploy, read the command.sh help output on a test host and confirm that the script's stack matches the release line you intend to run.
A manual install suits teams with an existing PHP platform or a standard database service they must reuse. The server configuration docs list PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15, served by Apache, Nginx or IIS. Background jobs need cron or a scheduled task, and your team owns every layer of the stack.
- PHP and database versions: Stay within the PHP range and database versions the docs list. Anything outside that list is outside the documented support.
- Web server configuration: Set up TLS, security headers, file permissions and upload limits yourself on Apache, Nginx or IIS.
- Cron or scheduled task: Without it, workflows, scheduled actions and background jobs stop. Monitor the job itself, not only the web page.
- Layer patching: Track PHP, database, operating system and web server security updates alongside each EspoCRM release, since no installer will do this for you.
- Paired backups: Back up the application files, uploaded attachments and the database together, then test restores to confirm they match.
Before you choose this path, check the current PHP and database versions in the server configuration docs against your platform's own support dates.
What a move from Dynamics 365 Sales to EspoCRM involves
The sequence moves your sales data, customizations and sign-in from Dynamics 365 Sales into EspoCRM in an order that keeps every entity, workflow and integration accounted for before users switch. The result is a self-hosted CRM that your team has tested against real records before the Dynamics 365 subscription is retired.
Inventory entities, fields, workflows and integrations
Start by listing every table, custom field, business process flow, workflow, report and integration that your sales team relies on in Dynamics 365 Sales. Include the Outlook add-in, Microsoft 365 links, Power Automate flows and any reports built on Dataverse views. Assign an owner to each item and mark which ones must work on day one and which can wait. Done means the list has an owner and a keep, change or retire decision for every line, and your sales operations lead has signed it off.
Confirm the export method with Microsoft guidance
Before you extract anything, confirm which export routes your Dynamics 365 Sales edition and tenant support for the tables you need. Views exported to Excel are limited in size and do not capture every relationship, so teams usually need a complete table copy for accounts, contacts, opportunities and activities. Check Microsoft's current export documentation and your administrator's permissions, and confirm the file format and record counts with the vendor or your Microsoft partner. Done means you have a written export method for each table and a test extract that opens correctly.
Export accounts, contacts, opportunities and activities
Extract the core sales tables in full, along with lookup relationships, owners, teams and attachments where they matter to your business. Keep the raw exports untouched in a secured location, and record row counts and checksums for each table. Activities such as emails, tasks and appointments often need separate handling because they link to several parent records. Done means every exported table reconciles with its source row count and a sample of records has been checked by a salesperson against Dynamics 365 Sales.
Map fields to EspoCRM entities and the import docs
Create the target entities, fields, field types and link relationships in EspoCRM using the Entity Manager, then map each Dynamics 365 column to its EspoCRM equivalent. Use the EspoCRM import documentation to confirm required fields, ID handling, duplicate checks and how multi-value or relationship data is loaded. Load the data into a staging instance first, and keep a mapping table that records every transformation. Done means a test import completes without errors and a sample of imported records matches the source in every mapped field.
Rebuild business process flows with the Advanced Pack
Recreate the stage logic, approval steps and automated actions that Dynamics 365 Sales enforces through business process flows and workflows, using the Advanced Pack's Business Process Management and workflow features. Formula Script can handle before-save logic and field calculations where a simple workflow is not enough. Test each flow with the people who use it, including edge cases such as reassignments and closed-lost deals. Done means every flow on your keep list has a test case, a documented owner and sign-off from the business process owner.
Repoint Outlook, Microsoft 365 and sign-in for users
Configure the EspoCRM integrations your team needs, such as the official Outlook extension, and confirm how email capture and calendar sync will work with your Microsoft 365 tenant. Set up OpenID Connect sign-in with Entra ID, decide whether users are created on first login and how identity provider groups map to EspoCRM teams, and provide a fallback login method for administrators. Confirm with your identity team how EspoCRM's own two-factor option interacts with OIDC, since the docs say they are not compatible. Done means a pilot group signs in, syncs email and calendar items, and reaches the right teams without shared accounts.
Run a parallel period and cut over
Run both systems for a defined period with a named group of users, reconcile new records between them, and log every defect with an owner and a fix date. Confirm backups, the cron job that EspoCRM needs for background tasks and the upgrade procedure before you go live. Agree a cutover checklist with business sign-off, switch users to EspoCRM as the system of record, and keep the Dynamics 365 export archived for audit and retention needs. Done means the reconciliation report shows no open critical defects, users have confirmed their daily work, and the archive is verified.
Questions buyers ask before a Dynamics 365 Sales to EspoCRM move
What does moving from Dynamics 365 Sales to self-hosted EspoCRM cost?
The EspoCRM software is free under AGPL-3.0, so the cost is the infrastructure, the migration, the configuration and the people who run the system. Dynamics 365 Sales costs recur per user, while self-hosting shifts spending toward one-time migration and configuration work plus ongoing hosting, backups, patching and support. The EspoCRM pricing page lists EspoCRM Cloud per-user plans, which is a useful comparison point if you want a managed option instead of your own servers. Ask any implementation partner for a fixed-scope quote that separates data extraction, entity mapping, workflow rebuild, identity setup, testing and run costs, and confirm what your Microsoft licensing terms allow you to export and when.
How long does a Dynamics 365 Sales to EspoCRM migration take?
The duration depends mainly on how many entities, custom fields, workflows and integrations you have, how clean your Dataverse data is, and how many users must be trained before cutover. No supplied figure gives a standard timeline, so treat any number you hear as a claim to test against your own inventory. Start by counting customized tables and business process flows, then check how many Outlook and Microsoft 365 connections depend on the current system. A fixed-scope plan should state the migration waves, the parallel-run period and the cutover window in writing before work begins.
What does a migration need from our IT and sales operations staff?
Sales operations owns the business rules, and IT owns hosting, identity and data handling, so both teams need defined roles from the start. Sales operations should sign off on the entity model, pipeline stages, required fields, duplicate rules and report definitions, since these become EspoCRM configuration in the Entity Manager. IT should provide the hosting environment, database service, certificates, backup storage, and access to Entra ID for sign-in testing. Expect sales operations to spend time validating migrated records and expect IT to review server, cron and backup settings before go-live.
Can our internal team migrate to EspoCRM without outside help?
An internal team can do it if it has someone who understands the Dynamics 365 data model, has administered PHP and SQL services, and can own the system after go-live. The risks usually sit in data extraction, workflow translation and integration testing, where small mistakes affect reporting for months. Teams that choose to do it themselves should pilot with one sales team, document every mapping and keep the old system read-only until reconciliation is complete. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope agreed in writing before work starts.
How are Outlook and Entra ID sign-in handled after the move?
EspoCRM supports OpenID Connect sign-in, so Entra ID can authenticate users, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. You should also confirm the fallback login method, since EspoCRM's own two-factor authentication is not compatible with OIDC, which means you rely on Entra ID for multi-factor sign-in. Outlook is different: the official EspoCRM Outlook extension is an add-on, so confirm its current compatibility with your Outlook version and how it handles mailbox sync before you rely on it. Test the team mapping, logout behavior and mailbox integration with a pilot group.
How do we keep audit and security evidence after leaving Dynamics 365?
Evidence comes from the configuration, the logs and the access records that you keep, and EspoCRM supplies some of this through its roles, API users and authentication settings. Document who has administrator rights, how API access is granted (HMAC is described as the most secure method and basic authentication is not recommended), and how OIDC and any LDAP settings are configured. Keep backup and restore test records, patch history and change approvals in one place. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, which remain the job of independent auditors and certification bodies. Confirm the evidence list with your auditor before the migration starts.
What does EspoCRM need to run reliably in production?
EspoCRM needs a supported PHP version, a database engine and a web server, and it depends on scheduled jobs for background tasks. The server configuration docs list PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, on Apache, Nginx or IIS. Background jobs require cron or a scheduled task, and a missed job often shows up as delayed workflows or stalled emails rather than an obvious outage. Add monitoring for the job queue, test restores of the database and file store, and confirm the upgrade path against the current release notes before each change window.
Which Dynamics 365 features does EspoCRM not replace out of the box?
EspoCRM covers core CRM records, configurable entities, workflows and business process management through the Advanced Pack, and a REST API, but Dynamics 365 is a broader platform. Plan for gaps in areas such as Power Platform automation, Copilot, Azure Synapse Link reporting and any custom Dataverse plug-ins, and decide which of these you need to rebuild, replace or drop. Map each Dynamics 365 capability you use to an EspoCRM feature, an official extension or a custom build, and confirm any gap with the EspoCRM documentation or your own testing before you commit.
How DeployOpen helps teams evaluate and move to EspoCRM
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Dynamics 365 Sales to EspoCRM, we start by mapping your Dataverse entities, workflows and sign-in requirements to what EspoCRM provides and what you would need to build or run yourselves.
How we scope
- We confirm which Dynamics 365 Sales entities, business process flows and reports your sales team relies on today
- We agree in writing which EspoCRM extensions, such as the Advanced Pack, and which integrations are in scope
- We document the sign-in design with Entra ID through OIDC, including user creation and team mapping decisions
How we build
- We deploy EspoCRM on your servers or cloud accounts with the supported PHP, database and web server versions
- We configure entities, fields, layouts and Formula Script workflows to match the processes agreed in scope
- We test API access with dedicated API users and role-based permissions before any sales data moves across
How we hand over
- We deliver the configuration record, server build notes and the backup and restore procedure for your team
- We document the cron or scheduled task setup that background jobs require, and how to verify it runs
- We walk administrators through user, role and team management so day-to-day changes stay in your hands
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover
- We can plan EspoCRM upgrades against the release notes and test each one in a staging copy first
- We can help you confirm, with your own review, which compliance evidence your CRM controls can produce
