Find the application and its accounts.
We need to identify the code, hosting, database, document storage, model provider and background jobs. We also check who owns the accounts and whether you have the rights and access needed for a handover.
Start with a description; secure access can be arranged after the scope is agreed.
Understand the current behaviour.
Show me the main tasks, the people using it and the issues you already know about. We check the software and services it relies on, and how it handles access, requests, data and provider failures.
The initial review identifies work rather than assuming every existing app is ready to migrate.
Check the data and spending routes.
The model bills, request logs and storage arrangement help establish what the service is doing. We look for exposed credentials, unclear permissions and missing usage controls. Any remedial work is listed separately from the hosting fee.
Plan a reversible move.
The migration plan names what is copied, how the result is checked, when traffic changes and how to return to the old route if needed. Backups and recovery checks come before the switch. Data handling and access arrangements are agreed for the actual services involved.
Make ownership understandable.
The proposal states which accounts remain yours, what I manage and what the original developer or another supplier still handles. New features are separate from taking over the existing running service. Handover notes should make a future move possible too.