Sometimes the existing system can continue after an orderly handover. Sometimes a deeper review, infrastructure fixes, completed backups, or a decision that part of the system is no longer worth maintaining as it is come first.This guide is for business owners who already have an app, a web system, a complex site, or an internal product, and want to move maintenance to a new developer without losing control of the code, the permissions, and the knowledge.
1. Do you need to start from scratch?
A rewrite cannot be ruled out in advance. The decision depends on the state of the code, the infrastructure, the database, the documentation, how much depends on the previous vendor, and whether the product can be built and run without putting users at risk.If there is orderly access to the code, a test environment, a clear build and deployment process, and a current backup, it is often possible to continue gradually. If critical parts are missing or the system is very fragile, stabilization, an upgrade, or replacing parts may come first.
- Is there access to the code repository and the latest version?
- Can a development or test environment be started?
- Is it known where the system is hosted and how it is deployed?
- Are there failures, old dependencies, or blockers that prevent ordinary maintenance?
2. Which assets need to be handed over
A maintenance handover is more than passing along a specification file. Every asset that runs the product should be under the business's control, or accessible in an orderly way to the new developer.Keep one list of what exists, who owns each account, who manages it today, and the right way to grant access without exposing unnecessary passwords.
- Code repositories, active branches, and permissions for Git or the code-management tool.
- Hosting infrastructure, servers, cloud services, logs, and development or test environments.
- Databases, backups, data-management tools, and access permissions.
- Domain, DNS, security certificates, and email settings if they belong to the product.
- App store accounts, if this is a mobile app.
- Third-party services such as payments, email, SMS, maps, analytics, or support.
- The build and deployment process: how a release is created and how it goes live.
- Existing documentation, specifications, diagrams, product decisions, and the list of open issues.
3. How to transfer permissions without putting passwords in a document
Do not pass passwords inside a specification, a shared spreadsheet, or a WhatsApp message. Use each service's invitation flow: a new user, a suitable role, and a permission that can be revoked later.Technical secrets such as API keys, deployment keys, database passwords, and tokens should be managed in a proper secret-management tool or in the hosting environment settings, not as free text in documents.
- Grant access by need: read, develop, administer, or billing, and not always owner access.
- Replace old secrets if it is unclear who was exposed to them in the past.
- Check who still has access after the work with the previous vendor ends.
- Record where secrets are managed without writing the values themselves in a document.
4. What to check before you finish with the previous vendor
Before closing the work with the previous vendor, confirm that the business holds access to the core assets, not only to a product that happens to work right now. After the relationship ends, it is harder to fill in knowledge, get invitations to accounts, or understand a manual deployment process.Ask for an orderly handover before the relationship with the vendor ends.
- Confirm that ownership or access to the core accounts sits with the business.
- Ask for an explanation of the build and deployment process, including test and production environments.
- Check that there is a current backup and that someone knows how to restore it.
- Collect documentation, product decisions, diagrams, and the list of open issues.
- Remove permissions that are no longer needed only after the new access has been tested.
5. An initial review before taking responsibility
Before promising ongoing maintenance, you need to understand whether the product can be maintained. An initial review shows whether the problem is only disorder, or whether there are deeper blockers that must be handled before development continues.The review does not have to fix everything in one day. The goal is a clear picture: what works, what is fragile, what is missing, and what is risky to touch without a backup or a test environment.
- The ability to build, run, and test the project in an environment that is not production.
- Dependency on the previous vendor: knowledge that exists only with them, accounts they own, or manual processes.
- Versions of libraries, languages, databases, and external services.
- Critical failures, fragile areas, and flows that users depend on.
- The state of backups, data restore, and a plan for when something fails.
- Gaps in documentation, missing permissions, or parts whose owner is unclear.
6. How to make a gradual transition
A good transition does not start with a large change in production. First confirm there is a way to test and roll back, and only then make a small change.
- Set up or confirm a test environment before a significant change.
- Confirm there is a current backup and a restore process someone knows how to run.
- Prepare a rollback plan in case a new release fails.
- Check core flows such as sign-up, sign-in, payment, creating an order, messages, reports, or admin screens.
- Start with a small change or a limited fix before a large development effort.
- Record what was tested, what was found to be sound, and what needs later work.
7. What to do when some of the code or access is missing
If code, server access, a store account, or documentation is missing, do not assume it is acceptable to bypass protections or enter a system without authorization. Start from what the business controls: official accounts, the domain, DNS, stores, cloud vendors, backups, and legal or operational documents.Sometimes part of the picture can be recovered from existing accounts, backups, production releases, or documentation. Sometimes you need to contact the previous vendor, the infrastructure providers, or suitable legal or operational advice before making a technical change.
- Check whether backups, build packages, or documentation can help.
- Separate what can be maintained now from what needs recovery or rebuilding.
- Document risks before changing production.
8. What a maintenance intake review can include
A maintenance intake review is a relatively short process whose purpose is to understand the product's state before committing to ongoing work. It does not promise that everything is sound. It provides a basis for a decision: what can be maintained, what is risky, and what needs to be put in order first.
- A map of the code, infrastructure, databases, and third-party services.
- Build and run status: what works, what fails, and what is missing.
- A list of permissions and secrets that need to be arranged or replaced.
- A check of backups and the test environment.
- Risks that block safe maintenance or a calm deployment.
- A gradual onboarding plan with first tasks and priorities.
9. What to include in the first month of maintenance
The first month should not be only a feature list. It is usually right to combine stabilization, filling in knowledge, handling urgent failures, and planning the work ahead.If everything is sound, development tasks can start too. If blockers appear, handle what makes safe maintenance possible first: access, backups, the deployment process, and basic documentation.
- Mapping code, infrastructure, accounts, environments, and deployment processes.
- Arranging permissions and replacing secrets that are not managed properly.
- Checking backups and basic restore processes.
- Handling critical failures that affect users or the business.
- Setting up an ordered task list by urgency and value.
- Planning a small release or a first improvement that can be tested safely.
10. What affects the scope of work
There is no fixed scope that fits every system. A small product with orderly code and full access can be taken on faster than a large system with no documentation, old dependencies, or several external vendors.
- The size of the system and the number of apps, services, or admin interfaces.
- Code quality, documentation level, and the ability to run tests.
- The number of integrations and external services the product depends on.
- The state of infrastructure, backups, permissions, and the deployment process.
- The urgency of failures, active users, a nearby release, or app stores.
- Whether the plan is to keep maintaining, upgrade gradually, or replace parts.
An example transition plan
A short, controlled move to a new developer
- First week: receive access to the code repository, infrastructure, database, stores, and third-party services through orderly invitations.
- Initial review: run the project in a test environment, check the build, review the deployment process, and map open issues.
- Stabilization: complete a backup, run a basic restore check, replace sensitive secrets, and close permissions that are not needed.
- First task: a small fix or a limited improvement, with a test and a rollback plan before going live.
- Next: prioritize tasks for the coming month by urgency, value, and risk.
Preparation list for a maintenance handover
Even if you do not have every detail, this list helps show what to collect before a new developer enters an existing system.- A link to the code repository and an explanation of which version is in production.
- A list of accounts and infrastructure: hosting, database, domain, DNS, and stores.
- A list of third-party services the system uses.
- A short description of the build and deployment process, if one exists.
- Access to a test environment, or a decision that one needs to be created.
- The state of backups and who knows how to restore them.
- A list of urgent failures and open tasks.
- A contact at the previous vendor, if a handover is needed.
Common questions
Can you always continue without a rewrite?
Not always. First check the code, infrastructure, backups, permissions, and failures. If the system is stable enough, you can continue from it. If there are heavy blockers, infrastructure repair, a gradual upgrade, or replacing parts may be needed.
What if the previous vendor does not cooperate?
Start from what the business controls: accounts, the domain, stores, hosting, backups, and code repositories. If critical assets are missing, the legal and operational path to restoring access needs to be understood before a technical change begins.
Does the new developer need owner access to every account?
Not necessarily. Prefer permissions by need through invitation flows, and keep owner access with the business. Where a higher permission is required, set it deliberately and record why it is needed.
Can new features start immediately?
Sometimes yes, but only after a basic check shows the product can be built, tested, and deployed safely. If there is no test environment, no backup, or no clear deployment process, put those in place before a large feature.
How long does it take to take on an existing system?
It depends on the size of the system, code quality, documentation, the number of integrations, how available the access is, and how urgent the failures are. A fixed duration should not be set without seeing the product.
Want to review an existing system before a maintenance move?
You can send a short description of the product, what already exists, and what is most urgent to solve. We will start with an initial review and say whether it is right to continue on the existing system or whether a deeper check is needed.Want to review an existing system before a maintenance move?
You can send a short description of the product, what already exists, and what is most urgent to solve. We will start with an initial review and say whether it is right to continue on the existing system or whether a deeper check is needed.