You have decided to change your ERPNext partner. Then someone asks where the custom app is stored, who controls the hosting account and whether the latest backup has ever been restored. The answers are unclear.

That uncertainty matters when your team still needs to dispatch orders, receive stock and close accounts. An ERPNext support takeover transfers responsibility for an existing installation to another provider. The new team needs enough access, knowledge and evidence to understand what it is accepting.

ERPNext Support Takeover

This guide explains what to collect, what to assess and how to verify the handover. The checklist is a recommended business framework, rather than an official mandatory Frappe procedure.

What Kind of ERPNext Takeover Do You Need?

Support takeover, unfinished implementation or system recovery?

Start by describing the condition of the system. Slow ticket responses do not prove that the implementation needs rebuilding. An unfinished project may need completion work before it is ready for routine support.

Situation	Engagement to assess	First question
Working system; unsatisfactory support	Support takeover	Can the incoming team maintain the current setup?
Promised processes remain incomplete	Implementation completion	What was delivered and accepted, and what remains?
Transactions, data or customisations cause problems	Recovery and stabilisation	What causes the problems, and what can be repaired?
Hosting must move	Migration alongside the relevant engagement	Can the installation be reproduced and validated elsewhere?

For deeper recovery questions, see our guide to ERPNext implementation failures.

Does hosting also need to change?

Changing partners does not automatically require changing hosting. Establish whether the existing arrangement can give the incoming provider authorised access and workable responsibilities.

Migration becomes a separate decision if account control, infrastructure suitability or service terms require a move. Ask the proposed partner to explain why migration is necessary before treating it as part of the takeover.

What to Confirm Before Appointing a New Partner

Map access and control

Record who controls the ERPNext site, hosting account, code repositories, domain/DNS and connected services. Having an ERPNext login does not establish control of the hosting subscription or permission to transfer it.

Access also depends on deployment. A managed-cloud installation may offer dashboard controls rather than unrestricted server administration. On Frappe Cloud, team membership provides account access; confirm the appropriate team arrangements before granting access.

For each account, identify the business contact who can authorise changes. This makes the transition easier to coordinate when several providers are involved.

Review existing commitments

Collect the proposal, statement of work, support terms, acceptance records and subsequent changes. Identify notice provisions, unfinished deliverables, payment matters and custom-code licensing or handover terms.

ERPNext’s open-source availability does not settle every contractual question about separately developed code or third-party accounts. Obtain appropriate advice where the actual terms are unclear.

Define the business priorities

Name an internal decision-maker and the users responsible for critical processes.

Replace “inventory is wrong” with a specific example: “The branch transfer report does not match these three transactions.” Concrete evidence helps a new provider assess scope before proposing fixes.

Also identify the activities that cannot be interrupted, such as dispatch, production reporting, payroll or month-end accounting.

ERPNext Support Takeover—The Handover Checklist

Use one register throughout the transition. Record an accountable person for each item and mark it received, verified, missing or unresolved.

Receipt means the information arrived. Verification means someone checked that it works or represents the deployed system.

Handover item	Evidence required	Current controller	Verification method	Status / action owner
Site and hosting access	Account details, authorised roles, billing contact	Business, partner or host	Confirm permitted administrative actions	Record status and owner
Versions and apps	Version list, app list, deployment records	Hosting/development team	Compare with the running installation	Record status and owner
Custom apps	Repository access, deployed revision, licence, dependencies	Developer/repository owner	Match code to deployment; check test setup	Record status and owner
Site customisations	Fields, workflows, scripts, reports, print formats	Functional/development team	Inspect and test significant business rules	Record status and owner
Backups and configuration	Database/file backups, relevant configuration, required keys	Host/site administrator	Controlled restoration and validation	Record status and owner
Integrations	Connection map, account controllers, schedules, error records	Business/third parties	Validate an authorised test transaction	Record status and owner
Process knowledge	Process maps, decisions, training and acceptance records	Business/outgoing team	Walk through workflows with process owners	Record status and owner
Open work	Tickets, defects, workarounds, unfinished deliverables	Business/outgoing team	Reproduce, classify and assign	Record status and owner

Deployment, versions and installed applications

Record ERPNext and Frappe versions separately, alongside every installed app.

Distinguish standard ERPNext, other Frappe ecosystem apps, third-party apps and bespoke applications. Identify production and test environments, deployment method and known compatibility constraints.

Include recent update history where available. The deployed revision matters: a repository’s latest branch may differ from the code running in production.

Customisations and source code

Inventory both custom apps and site-level changes. Custom Fields, workflows, scripts, reports and print formats should have a recorded business purpose.

Identify modifications to standard application code separately so the incoming team can assess their maintenance implications.

For each custom app, establish repository access, applicable licensing, dependencies and the deployed revision. A screen showing a custom feature is insufficient evidence that another team can maintain its implementation.

Our custom app development guide provides related context.

Backups and restoration requirements

Record backup location, frequency, retention, access and the latest successful backup. Check database backups and public/private file archives, relevant site configuration, application code and any required keys.

Frappe’s Bench restore documentation distinguishes database restoration from public and private file restoration. A database backup alone does not establish that attachments and the full working environment can be recovered.

Frappe Cloud backup documentation also describes backup access and optional backup encryption. Check the actual site’s arrangements rather than assuming that every installation has the same backup coverage.

Request a controlled test restore with documented results. Keep backup-decryption requirements and keys needed for stored application secrets identified separately where applicable.

Integrations and external services

List connections actually present, such as email, payment gateways, ecommerce, Tally connectors or devices.

Record account controllers, schedules, endpoints, error handling and monitoring. For each connection, identify who investigates failures and who can authorise changes.

Store credential references in the register. Transfer passwords, tokens and keys through an agreed secure channel. Identify whose identity each integration uses before revoking outgoing accounts.

Business documentation and unfinished work

Collect configuration decisions, training material and process maps. List known defects, workarounds and outstanding tickets.

Keep accepted deliverables, unfinished work and disputed scope distinguishable so the incoming partner can quote against an explicit starting position.

Where written documentation is limited, identify the users who understand each workflow. Their knowledge can help explain why the system behaves as it does.

What the Incoming Partner Should Assess

Technical condition and maintainability

The assessment should establish compatibility, deployment reproducibility, background-job health, recurring errors and integration condition. It should identify customisations that need attention before an upgrade or support commitment.

Agree assessment access and limits first. Inspection should not become an undocumented series of production changes.

Critical business workflows

Validate representative transactions with the people who use them. Choose workflows relevant to the organisation: order-to-receipt, purchase-to-payment, inter-warehouse transfers or manufacturing and quality.

Consider a hypothetical distributor with several branches. The site opens normally, but a branch-transfer customisation generates an incorrect report.

A useful assessment follows a transfer through its records and reporting, with the inventory owner confirming the expected result. A login check would miss the business problem.

For an Indian business using a separate compliance app or filing integration, include that dependency in the assessment where present. Do not assume every installation handles compliance through the same applications.

Findings and recommended scope

Expect a prioritised issue register separating infrastructure, configuration, data, training and development needs.

It should state assessment limitations and recommend what can enter ongoing support versus what requires remediation. This establishes scope for the implementation work that may remain.

The output should help the business understand what needs immediate attention, what can wait and what remains uncertain.

How to Handle Missing Access or Documentation

Classify what is missing

Different gaps have different consequences. Missing training notes may be reconstructed through interviews; unavailable custom-app source can obstruct maintenance or redeployment.

Gap	Consequence	Next action	Responsible party
Process documentation absent	Business rules remain uncertain	Interview users and validate workflows	Process owner and incoming team
Hosting account unavailable	Hosting actions or transfer may be blocked	Resolve authorised access with controller/provider	Business and account controller
Custom-app repository missing	Code maintenance or redeployment uncertain	Establish access, licensing and available code	Business and developer
Restore evidence absent	Recovery capability unproven	Arrange a controlled restoration test	Incoming technical team

Agree what can proceed

Create a limited scope around available evidence. Record blocked activities and reconstruction effort explicitly.

Missing access should be resolved through authorised account and contractual channels. A new partner cannot responsibly promise recovery before understanding those constraints.

If documentation needs reconstruction, agree who will validate the findings. An inferred business rule should not silently become an accepted requirement.

Agree Scope, Costs and Responsibilities Before Transition

Separate assessment, remediation and ongoing support

A takeover proposal should distinguish discovering the system’s condition, correcting existing problems and supporting accepted operations.

New features and unfinished implementation work need explicit treatment.

Ask each provider to clarify:

• Which inherited issues are included, excluded or awaiting assessment?
• Who maintains hosting, custom apps and external connections?
• How are additional work and change approvals handled?
• When does support responsibility begin?

Our guide to ERPNext support after go-live discusses ongoing service needs.

Explain what affects effort and timing

Documentation quality, custom-code complexity, data problems, integrations, access gaps and migration requirements all affect the work.

Business-user availability also matters: a technically ready system still needs validation by its process owners.

These factors make universal takeover prices or durations unreliable. Compare assumptions and deliverables before comparing monthly fees.

A lower support fee may cover fewer responsibilities. A larger initial assessment may include restoration testing or functional validation that another proposal excludes. Make those differences visible.

Define service expectations

Specify business hours, ticket channels, escalation, reporting and change approval.

Distinguish a response target from a resolution commitment: acknowledging a ticket does not mean the underlying defect is fixed.

Record what happens while a problem is being investigated and who coordinates third-party dependencies. Also agree the date on which each provider’s responsibility begins and ends.

Plan the Transition Around Business Continuity

If the installation remains in place

Transfer authorised access and operational knowledge. Agree who handles existing tickets and approves production changes during the transition.

Validate incoming access and integration dependencies before replacing credentials. Keep a record of changes so both teams understand the installation’s condition at handover.

If migration is required

Prepare a separate plan covering test restoration, workflow validation, cutover responsibilities, permitted downtime and rollback.

Prevent the test environment from sending live emails, processing real payments or duplicating scheduled integration activity.

Define the rollback decision point and how transactions created after cutover would be handled. “Return to the old server” is incomplete if new transactions exist only in the new environment.

Downtime expectations should follow the actual migration plan and testing results.

Communicate with users

Tell users where to raise tickets, when the change takes effect and who owns unresolved issues.

Frappe’s implementation procedure includes recorded support handover and customer notification. Those principles also provide a useful foundation for this recommended inter-vendor process.

Keep process owners involved until the workflows they are responsible for have been validated.

How to Verify and Accept the Handover

Agree acceptance evidence

Acceptance should show that the incoming team can perform its agreed responsibilities and that the business understands remaining gaps.

Check	Evidence	Verifier	Result
Authorised access works	Required actions demonstrated	Incoming technical lead	Pass / gap
Code and dependencies available	Deployment inventory and test evidence	Incoming developer	Pass / gap
Restoration validated	Restore record and agreed checks	Technical lead and business owner	Pass / gap
Critical workflows accepted	Recorded scenarios and outcomes	Process owners	Pass / gap
Support arrangements active	Ticket submission and escalation checked	Internal coordinator	Pass / gap
Remaining issues assigned	Issue register with scope and owners	Both parties	Accepted / unresolved

A remaining issue can be accepted with a named owner and agreed scope. An unrecorded issue leaves responsibility uncertain.

Record acceptance, outstanding actions and any limitations together. This gives the business a usable reference after the transition meeting.

Retire outgoing access in a controlled sequence

Review site users, hosting access, repositories and external-service accounts.

Revoke or replace outgoing access according to the agreed transition, checking shared credentials and automated connections. Record completed changes and retain the documentation needed for support and audit.

The sequence should allow the incoming team to perform its responsibilities while removing access that is no longer required.

Prepare Your ERPNext System for a Takeover Assessment

Start with the app inventory, access map and open-issue list. Mark what is verified and what remains uncertain. That gives prospective providers a clearer basis for assessing responsibilities and proposing work.

An ERPNext support takeover becomes easier to evaluate when both sides can see the evidence, dependencies and acceptance conditions.

Planning an ERPNext support takeover? Discuss your current setup and handover readiness with Turqosoft. Share your hosting arrangement, installed apps and main unresolved issues to establish the next assessment step.