Why SAP ECC customers are choosing open source ERP before the 2027 deadline
If your SAP ERP 6.0 landscape loses mainstream maintenance at the end of 2027, the board decision is no longer whether to move, but where each part of the business should land. Open source ERP is a realistic target only for some scopes. For the rest, the realistic choices are SAP S/4HANA, Odoo or ERPNext, or a maintenance bridge that buys time. SAP has committed to mainstream maintenance for core SAP Business Suite 7 applications, including SAP ERP 6.0, until the end of 2027. Customers can opt into extended maintenance from 2028 to the end of 2030 at a premium of two percentage points on the existing maintenance basis. Customers who do not opt in move automatically to customer-specific maintenance from 2028. SAP has also committed to maintaining SAP S/4HANA until the end of 2040. The exact contract terms, including how the premium applies to your agreement, should be confirmed with SAP in writing, and the primary text is in SAP's 2020 announcement on S/4HANA maintenance.
ECC is rarely one decision. It is a portfolio of processes, each with its own entities, currencies, industry rules and integrations. Finance and general ledger for a single country with a stable chart of accounts is a different problem from a multi-entity group with intercompany flows, a regulated product line, or a plant running a custom production planning setup. Odoo and ERPNext can cover many standard finance, purchasing, inventory and sales flows, but the fit depends on how much of your SAP estate is custom ABAP, how many integrations depend on IDocs or BAPIs, and which records must be retained and audited in a specific form. A sound first step is to split the landscape into scopes, mark each as move, stay on S/4HANA, or bridge, and record the owner, the integrations and the retention rules for each one.
The decision you need to make now is the bridge. Migration projects of this size cannot be completed in the months left before the end of 2027 for every scope, so the board should ask for a written position on extended maintenance, customer-specific maintenance and a phased cutover sequence before committing budget. Confirm with your implementation partner which scopes can cut over in waves, which custom reports and interfaces must be retired or rebuilt, and which regulatory retention obligations apply to the archived SAP data. Your evidence should show how each choice was reached, not only what was chosen.
Which regulatory and business requirements a replacement must still meet
This table maps the regulatory and business requirements a replacement ERP must still satisfy to their source, what each asks for in practice, and where migrations usually fail to carry the evidence across. The FTC and SEC obligations apply only if your organization is a covered financial institution or broker-dealer, so confirm scope with counsel before using the rows as requirements. Read each row as a design input for the new system, not as a compliance finding.
| Requirement | What it asks for in the new system | Where it usually fails in an ECC move |
|---|---|---|
| FTC Safeguards Rule, encryption (16 CFR 314.4) | Customer information encrypted in transit over external networks and at rest in the new ERP, database and backups | Interfaces and file transfers from ECC are rebuilt without encryption, and old extracts sit unencrypted on migration servers |
| FTC Safeguards Rule, MFA (16 CFR 314.4) | Multi-factor authentication for any individual accessing any information system, including admin and support accounts | Service and batch users keep password-only access, and MFA is applied to the front end but not to database or admin consoles |
| FTC Safeguards Rule, change management (16 CFR 314.4) | Documented procedures for changes to configuration, custom code and interfaces, with approval and testing records | Custom modules and configuration are changed directly during cutover without a recorded approval trail |
| FTC Safeguards Rule, activity logging (16 CFR 314.4) | Logs of authorized user activity that can be reviewed, retained and tied to named individuals | Logging is enabled for the application but not for the database or integration layer, so user actions cannot be traced end to end |
| FTC Safeguards Rule, testing (16 CFR 314.4(d)(2)) | Annual penetration testing and vulnerability assessments at least every six months, unless continuous monitoring is effective | Testing is scheduled for after go-live, leaving the new system untested during the parallel run and cutover window |
| SEC Rule 17a-4(b) retention (broker-dealers only) | Bills receivable and payable, bank statements and business communications kept at least three years, the first two easily accessible | Archived ECC records are exported to files that cannot be read in the new system, and retrieval time is not tested |
| Audit trail and change history from ECC | Ability to show who posted, changed or reversed a financial document, and when, for periods before and after cutover | Only opening balances are migrated, so the document history that supports prior-period questions is lost |
| Open items and reconciliation history | Open receivables, payables and clearing items carried over with references to their original documents and reconciliation sign-off | Open items are recreated as new documents without the original references, which breaks later matching and audit sampling |
When Odoo, ERPNext or S/4HANA fits an ECC replacement
A single legal entity with one chart of accounts, one currency set and a standard make-to-stock or make-to-order process is the most common fit for Odoo or ERPNext. The scope is usually inventory, purchasing, sales, production planning and finance, and these modules cover that ground in both platforms. The decisions turn on process details rather than on the platform brand, so the first step is a line-by-line comparison with your current ECC transactions.
- Module coverage: Confirm that bills of materials, routings, MRP and quality checks match how your plants actually run. Odoo's Manufacturing and ERPNext's Manufacturing modules differ in depth for specific cases.
- Edition choice for Odoo: On-premise hosting, multi-company and custom modules are available only on the Custom plan. A single-entity firm that wants all three should price that plan from the start.
- ERPNext licensing: ERPNext is licensed under GPL-3.0 and its Frappe Framework under MIT, so self-hosting carries no per-user license fee. Support then comes from your own team or a partner.
- Version lifecycle: Odoo 20.0 has standard support planned until September 2029, and ERPNext v16 is planned for support until the end of 2029. Choose the version line you will run for several years.
- What S/4HANA still does better: Deep industry templates, large-scale planning and integration with the wider SAP estate are stronger in S/4HANA. If your plants depend on SAP extensions, that weighs heavily.
Confirm module coverage against a written process list with each vendor and with an implementation partner before you commit.
A group with several legal entities, intercompany trading, currency translation and group consolidation has different requirements. In Odoo, the ability to run multiple companies in one database is restricted to the Custom plan, and that plan is also the only one that supports on-premise hosting. ERPNext handles companies inside one site, but intercompany and consolidation designs still need testing against your reporting structure. Shared master data and separate charts of accounts are the central design questions.
- Plan requirement: If one database must hold several entities, Odoo means the Custom plan. Confirm whether your group requires on-premise hosting, which also points to that plan.
- Intercompany flows: Test how intercompany invoices, eliminations and transfer pricing post across companies in your target platform, using your own sample transactions.
- Separate instances: Where entities differ widely in tax, currency or statutory reporting, separate instances can be the safer design, with consolidation handled outside the ERP.
- Consolidation tooling: Check whether group reporting needs a dedicated consolidation tool. Neither platform should be assumed to replace one without a test.
- What S/4HANA still does better: Group consolidation, intercompany reconciliation at scale and statutory reporting in many countries are mature in S/4HANA. Groups with complex consolidation rules often find that gap decisive.
Ask for a written multi-company design and a test of one intercompany cycle before you decide on the target.
Organizations that built deep custom ABAP over many years face the largest migration effort. Custom reports, enhancements and bespoke transactions do not move to Odoo or ERPNext as code. Each one must be retired, rebuilt as a standard configuration, or rebuilt as a custom module. The decision depends on how much of the custom code supports processes that still matter, and this is usually the largest single driver of scope.
- Code inventory: Classify every custom object as retire, replace with standard configuration, or rebuild. Retire decisions often remove most of the volume.
- Custom module upgrades: In Odoo, custom modules require the Custom plan and must be kept compatible with each major version. Odoo's upgrade service applies to Enterprise subscriptions on-premise. Confirm how an upgrade path would work for your modules.
- ERPNext server scripts: Starting from version 15, Frappe Server Scripts are disabled by default and must be enabled with the server_script_enabled setting. Public shared benches do not allow them, so custom logic may need a different hosting model.
- Interfaces: Count the inbound and outbound interfaces that ABAP code depends on. Those interfaces often matter more than the reports themselves.
- What S/4HANA still does better: Where custom ABAP is tightly coupled to SAP-specific logic, S/4HANA keeps that coupling and reduces rebuild work. The move to S/4HANA also carries its own custom code conversion effort, which you should estimate separately.
Ask each candidate platform for a sized inventory of your custom objects and a short written view of how each one would be rebuilt.
Regulated firms must keep records that auditors and regulators can read. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to encrypt customer information, enforce multi-factor authentication, adopt change management and log user activity. SEC Rule 17a-4(b) requires broker-dealers to preserve records such as bills receivable or payable and bank statements for at least three years, with the first two in an easily accessible place. Whether an ERP can meet these needs depends on how the migrated history and access controls are designed.
- History strategy: Decide which years must stay live, which move to an archive and which stay in a read-only copy of the ECC system. Confirm the retention period with your records officer and counsel.
- Access and logging: Verify that the target platform can enforce multi-factor authentication and record user activity to the level your regulator expects. Confirm the exact features in each platform's documentation.
- Change control: Plan change approval and testing for configuration and custom code from the start, since the ERP becomes part of your control environment.
- Assessment support: DeployOpen prepares systems and evidence for assessments, but independent auditors issue any opinion. Plan the evidence set with your audit team early.
- What S/4HANA still does better: Established audit trails, certified statutory reporting in many jurisdictions and vendor-backed controls documentation are stronger starting points. Many regulated firms keep S/4HANA for the finance core for that reason.
Confirm your retention and access requirements in writing with compliance and internal audit before choosing a target platform.
How extended maintenance buys time without locking in ECC
The decision in front of an SAP ERP 6.0 customer is not whether to keep running ECC after 2027, but which of three paths to take and what each one costs in budget and risk. Path one is to opt into SAP's optional extended maintenance, which SAP committed to offer from 2028 to the end of 2030 at a premium of two percentage points on the existing maintenance basis, according to SAP News. Path two is to do nothing by the end of 2027, which moves the customer automatically to customer-specific maintenance from 2028. Path three is to migrate earlier and treat any extension as a safety margin rather than a plan. Each path changes the contract, the staffing and the risk profile, so the choice should be made in the business case, not in the project plan.
Extended maintenance is a bridge, and a bridge only helps if it leads somewhere. The premium buys time for the program, but it does not remove the need for a named target platform, a scope, a data strategy and a cutover date. Customers who sign the extension and then defer the target decision often end up paying the premium for three years while the same dependencies remain open. A useful check is to write down, before signing, which decision must be made by which date for the extension to be worth its cost, and who owns each one. The same logic applies to customer-specific maintenance, where the risk shifts to the customer's own support model.
Before committing, confirm with SAP in writing what the extension covers: which SAP Business Suite 7 components and enhancement packages are included, what the premium is calculated on, whether it applies to your licensed user and module mix, how security patches and legal changes are handled, and what happens to support terms if the program slips beyond 2030. Ask for the customer-specific maintenance terms in the same conversation so the comparison is like for like. Your legal and procurement teams should also confirm notice periods and exit conditions. Figures and terms in SAP contracts vary by agreement, so treat any number from a public article or a partner estimate as a starting point to verify, not a commitment.
How a phased ECC exit runs from scope cut to cutover
The sequence turns an ECC estate into a scoped, migrated and reconciled set of target processes, so each entity or process area moves only after its balances and records have been proven in a parallel run.
Inventory the landscape and custom code
The team lists every ECC production client, company code, interface, batch job, report and custom development object, then maps each to an owning business process and a named business owner. Your SAP Basis team and the functional leads confirm which objects are still used by reading usage data for the last full fiscal cycle rather than relying on memory. The output is a landscape register and a custom code inventory with a keep, replace or retire flag on every item. The step is done when every interface and custom object has an owner and a disposition that the business has signed.
Cut scope and run fit-gap by process
Business leads and DeployOpen's solution architects agree which processes, legal entities, currencies and reporting obligations are in the first wave, and which stay in ECC or under extended maintenance for a later decision. Each in-scope process is then tested against Odoo or ERPNext standard functions, with gaps classed as configuration, process change, or custom build. The output is a signed scope statement and a fit-gap log where every gap has a decision and a cost owner. Confirm with the target vendor which edition, plan and modules cover each in-scope process before the log is closed.
Decide the target for each process area
For each process area, the team records whether the target is Odoo, ERPNext, a specialist application, or continued SAP use, with the reason tied to the fit-gap result and the integration load. Decisions cover the finance core, procurement, sales, inventory, manufacturing and any regulated financial flows. The output is a target architecture decision record that names the hosting model, the support route and the upgrade path for each target. The step closes when steering approves the record and the open questions have named owners and dates.
Carve out open items, balances and history
Data owners agree which open items, opening balances, master data and transactional history move into the target, and which stay in an archive. Records that must be retained for regulators, such as broker-dealer books and records under the SEC preservation rule or customer information subject to the FTC Safeguards Rule's logging and encryption expectations, are mapped to a retention schedule and a readable archive before extraction starts. The output is a data carve-out specification and a retention map signed by finance, compliance and the data protection lead. Confirm the retention periods with your counsel and records manager, since the cited rules set minimums that your own policy may extend.
Run trial loads in controlled batches
The team extracts data from ECC, transforms it to the target model and loads it into a non-production copy in batches sized to the target's import tooling, starting with master data and then open items. Each trial load is logged with record counts, rejected rows and the transformation rules applied, and failures feed back into mapping changes. The output is a repeatable load script and a defect log that shows the error rate falling across trials. Ask the implementation partner to show how a failed batch is re-run without duplicating records.
Parallel run and reconciliation sign-off
For at least one full close cycle agreed in the plan, transactions are processed in both ECC and the target, and balances, open items, tax totals and key reports are reconciled line by line. Differences are logged with a root cause and an accepted or corrected status. The output is a reconciliation pack signed by the controller and the business process owners for each in-scope area. Do not move to cutover until every material difference has a documented disposition, and confirm with your auditors which evidence they expect to see.
Phased cutover by entity or process
Cutover moves one entity or process area at a time, timed to a period end so that opening balances are clean and reporting continuity is preserved. The cutover runbook lists freeze windows, final extracts, load steps, interface switch-over, access provisioning and rollback criteria with named owners. The output is a completed cutover checklist, a post-cutover reconciliation and a hypercare log. The step is done when the first closed period in the target is reconciled to ECC and the remaining ECC scope is confirmed for its next wave or retirement.
Which open source platforms fit an SAP ECC scope and why
SAP ERP 6.0 customers need a target that matches their process scope, not just a lower license cost. The cards below compare the open source ERP options by edition, support model, customization depth and the kinds of ECC scope each one handles well, so the shortlist can be tested against real process inventories.
Odoo Community and Odoo Enterprise
Odoo Community is the LGPL-3.0 core, and Odoo Enterprise adds features such as Studio, upgrades and hosting on top of it. For an ECC replacement, the decision point is the plan: only the Custom plan can run on Odoo.sh or on-premise and includes multi-company, Studio, external API access and custom modules. Odoo 20.0 has standard support planned until September 2029, and Odoo 18.0 ends its standard support in September 2027. Confirm which version your upgrade path will target and whether your on-premise deployment needs the Enterprise subscription for the upgrade service.
ERPNext on the Frappe framework
ERPNext is GPL-3.0 licensed and built on the Frappe framework, which is MIT licensed. It can be installed with Docker Compose, the bench command line tool, or on Frappe Cloud. The frappe_docker repository provides production images with MariaDB, Redis, workers, the scheduler and Nginx. Plan the data load carefully: the Data Import tool is documented for a few thousand records at a time, so large ECC master data and open item loads need batching. Frappe's policy also ties warranty coverage to a listed version and a matching support plan, so check the version and plan before committing.
Server Scripts and custom logic
ECC scope often depends on custom reports, validations and posting logic. In ERPNext, Server Scripts run Python on document events or as API endpoints, but from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. Teams moving custom ECC logic should inventory each routine, decide whether it becomes a configuration, a server script or a proper app, and confirm where the hosting model permits each option before the design is fixed.
Apache OFBiz for ERP and MRP
Apache OFBiz is licensed under Apache-2.0 and includes framework components and business applications for ERP, CRM, ecommerce, supply chain management and manufacturing resource planning. It suits organizations with an in-house Java team that wants to build and own the application layer. The trade-off is effort: OFBiz typically requires more development and internal knowledge than packaged suites. Ask any partner for the OFBiz version they would support, the upgrade method for custom components, and who maintains the security patching after go-live.
Where open source fits poorly
Open source ERP fits poorly where ECC depends on deep custom ABAP, heavy enhancements or industry add-ons that have no open source equivalent. In those cases, the replacement cost moves into rebuilding business logic, not into licensing. Treat this as a test, not a verdict: list the custom objects, add-ons and interfaces that carry business rules, then score each one for whether it can be configured, rebuilt, retired or kept as a separate service. If most of the value sits in those objects, S/4HANA, extended maintenance or customer-specific maintenance may be the safer bridge.
What auditors and regulators will ask to see from the new ERP
This table maps the evidence an assessor or regulator is likely to request to the ERP component or process that produces it. Use it to design logging, change control and retention before cutover rather than reconstructing records afterward. DeployOpen prepares this evidence for your assessors, but independent auditors and regulators decide whether it is sufficient.
| Evidence item | What it shows | Where it usually fails |
|---|---|---|
| Change management records | Approval, testing and promotion of configuration and custom code from the ERP test database to production | Configuration changes made directly in production with no ticket or approval trail |
| Access and activity logs | Who accessed or changed financial records, and when, for authorized users | Logs not retained or forwarded outside the ERP host, so they cannot be shown later |
| MFA configuration for users | Settings showing multi-factor authentication enforced for every user with access to customer or financial information | Admin and service accounts excluded from the policy, or MFA enforced only at the identity provider and not checked in the ERP |
| Encryption in transit and at rest | TLS configuration for user and integration traffic, and encryption of database storage and backups | Internal database connections, backups or test copies left unencrypted or unverified |
| Penetration test and vulnerability assessment reports | Independent testing of the ERP and its interfaces at the frequency the applicable rules set, with remediation tracking | Testing scoped only to the web front end, or findings with no closure evidence |
| Data conversion reconciliation sign-offs | Signed reconciliation of migrated balances, open items and master data from SAP ECC to the new ERP | Sign-offs missing for opening balances, or reconciliations done on sample extracts only |
| Retention records for archived SAP data | Where archived ECC data and records are stored, the retention period applied, and how they can be retrieved for inspection | Archive not readable after the ECC license lapses, or retention periods not mapped to the rules that apply |
What to ask an implementation partner before committing to ECC exit
Start with how the partner runs fit-gap across your ECC landscape, because that determines whether the scope you sign is the scope you need. Ask for the list of processes they will assess, how they inventory custom code (Z-programs, user exits, enhancements, custom reports and interfaces) and which of those they will map to a standard Odoo or ERPNext feature, rebuild as a custom module, or retire. Ask who signs off each disposition and what evidence they keep. Then ask which processes they configure and which they rebuild, and whether the written scope names the rebuilt items individually. Ask specifically how they treat ECC-specific functions such as industry solutions, special ledger or material ledger settings, and interfaces to banks, tax engines and shop floor systems, and confirm these appear in the scope rather than in a later change request.
Next, ask how open items, history and archived data will be split between what migrates and what stays in a read-only archive. Ask for their approach to opening balances, open customer and vendor items, and open purchase and sales orders, and who reconciles each load against ECC. For custom modules, ask how they keep them upgradable: whether they use the Odoo inheritance model or Frappe DocTypes and hooks instead of editing core files, how they version and test them against the next major release, and who pays for that work each year. Confirm whether Frappe Server Scripts are used at all, since the Frappe documentation says they are disabled by default from version 15 and Frappe Cloud public shared benches do not allow them. Ask who owns localization and tax for each country and how statutory reports are validated before go-live.
Finally, ask how the parallel run and cutover weekend are controlled, and what the partner's written scope excludes. Request the cutover runbook, the parallel-run comparison method, the rollback criteria and the named decision owner for go or no-go. Ask how support after go-live is delivered, for how long, and whether it is a fixed-scope hypercare phase or a retainer. Then read the exclusions carefully: training, data cleansing by your team, third-party interfaces, licensing and hosting costs, and future upgrades are common gaps. Ask the partner to state in writing which items are fixed-scope, which are time and materials, and what triggers a change request. If the partner cannot answer these questions in writing before work starts, treat that as a signal about the engagement.
Questions buyers ask about replacing SAP ECC with open source ERP
How much does replacing SAP ECC with open source ERP cost?
The cost depends mainly on scope, number of legal entities, custom code and data history, and no supplied figure sets a total for a migration of this kind. Software is a small share of the picture for Odoo Community and ERPNext, since self-hosting ERPNext is free according to the ERPNext pricing page, but Odoo Enterprise and Odoo's Custom plan are paid. The larger components are fit-gap analysis, configuration, custom modules, data migration, testing, training and support, and each is paid to whoever performs it. Hosting is recurring: the ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month and dedicated servers from 125 US dollars per month, while your own cloud or data center costs are separate. Ask any partner for a fixed-scope quote that separates one-time work from recurring licenses, hosting and support, and that lists each module, entity, interface and custom report in scope.
How long does an SAP ECC to open source ERP migration take?
The schedule follows the phases and the written scope, so it cannot be stated responsibly before the scope is fixed. A typical sequence covers discovery and fit-gap analysis, design, build and integration, data trial loads, testing, training, and a phased cutover, with each phase gated by sign-off. Timelines grow with the number of entities, interfaces to banks, payroll and tax systems, custom ABAP to rewrite, and years of history to migrate or archive. Plan the deadline around SAP's dates: mainstream maintenance for SAP ERP 6.0 runs to the end of 2027 according to SAP News, so the work must be sequenced against that date. Ask the partner for a phase plan with entry and exit criteria for each gate, and for the dependencies on your side.
What does the client team need to provide for an ERP migration?
The client team must supply named process owners who decide how each business process should run, data owners who certify master data and opening balances, and an accountable sponsor who signs off each phase and the cutover. Finance, procurement, sales, inventory and HR each need subject-matter experts who can make decisions within days, not weeks. Your IT team owns access to the source SAP system, network and hosting decisions, identity integration and the security controls that apply to the new platform. Reconciliation sign-off is a client duty: finance must confirm that migrated balances agree with the legacy ledger before go-live. Ask any partner to list these roles, the time each person must commit, and the decision log they will keep.
Can our internal team replace SAP ECC with open source ERP without a partner?
Internal teams can deliver simple scopes, such as one entity, a standard chart of accounts, limited custom code and a small history, especially with Odoo Community or ERPNext where documentation and community resources are available. Regulated or multi-entity scopes are harder to run alone because they add control evidence, segregation of duties, change management and cutover risk. Your team must be able to operate the platform after go-live, including backups, patching, upgrades and access reviews. If your staff has not run an ERP migration before, a partner can bring method and testing discipline, or you can use a partner for specific pieces such as data migration and testing. Ask a candidate partner which parts they would hand back to your team and which they would keep.
Do we need SAP extended maintenance before migrating to open source ERP?
No. Extended maintenance is optional and is not a prerequisite for moving to another platform. SAP said that customers who do not opt into extended maintenance by the end of 2027 move automatically to customer-specific maintenance from 2028, and that extended maintenance from 2028 to 2030 carries a premium of two percentage points on the existing maintenance basis, according to SAP News. Extended or customer-specific maintenance can therefore act as a bridge if the migration will run past 2027. Compare the premium cost with the cost of a longer parallel run and confirm with SAP which support terms apply to your contract. Your own legal and procurement teams should confirm the contract position before you choose a route.
What happens to upgrades after an open source ERP goes live?
After go-live, upgrades become a recurring task you must plan, fund and test. For Odoo, standard support covers the first three years after a major release on Online, Odoo.sh and on-premise, and major versions on Odoo Online and Odoo.sh are mandatory every two years, according to Odoo's upgrade documentation. On-premise upgrades need an Enterprise subscription because the Community edition has no access to the upgrade service. For ERPNext, Frappe lists version 15 as supported until the end of 2027 and version 16 until the end of 2029, and warranty coverage requires a matching Frappe Cloud support plan. Keep custom modules and server scripts in version control, test each upgrade on a copy of production, and confirm with the partner who owns that work after go-live.
How DeployOpen scopes and delivers an ECC exit
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open source ERP inside the client's own infrastructure, whether that is a cloud account, a data center or an isolated network. For an ECC exit, that means the target platform, whether Odoo or ERPNext, runs in your environment under your control, and DeployOpen's work covers the whole path from the first scope workshop to post-go-live support. The scope itself is the first decision. Before any build starts, the written scope should name the legal entities, the SAP modules being retired, the modules being rebuilt, the custom ABAP reports that will be dropped or re-created, and the interfaces that must survive the cutover. Ask for the scope in writing, with each phase's deliverables, acceptance criteria and exit conditions listed separately.
Most engagements are fixed-scope, so the written scope, deliverables and timeline are agreed before work begins. That structure matters for an ECC exit because the cost drivers are largely visible at scoping: the number of company codes, the volume of open items to convert, the count of custom developments, and the number of integrations. Ask for the quote to break out fit-gap analysis, configuration, custom modules, data conversion and reconciliation, testing, training, cutover support and hypercare as separate lines, so you can see which items are one-time and which recur. Ongoing work such as upgrades, security patching and continuous testing is available as a retainer, and it is worth agreeing its response expectations in writing before go-live. DeployOpen does not publish a price list, so the quote follows from the scope rather than from a rate card.
DeployOpen also prepares systems, controls and evidence for compliance assessments, including change records, access reviews, backup and restore results and configuration baselines. It does not issue audit reports, attestations or certifications; those come from independent auditors and certification bodies. Ask early which evidence your auditor will require, which retention periods apply to the records being migrated, and who signs off each control. Where a control depends on a platform behavior you have not verified, such as how the chosen edition handles audit logs or upgrade approvals, confirm it with the vendor and in a test environment before committing the design.
