Where is custom software data stored, and can the client change development teams?

A custom system can store data in the client's cloud account or private infrastructure, or in an environment managed by the provider. The safest default is for production databases, object storage, domains, and critical third-party accounts to belong to the client, with the developer using restricted subaccounts. A complete handover of code, data, tested recovery, configuration, and documentation should allow a replacement team to operate without waiting for the former provider to “release the keys.”

“Where” includes physical or cloud region, the legal entity holding the account, access control, backup, and export. A database may be in the client's chosen cloud while the supplier still controls the master account, encryption key, domain, or payment and messaging accounts. Conversely, managed hosting does not automatically remove the client's rights, but export and exit terms must be explicit.

When agreeing deliverables, handover, and ownership boundaries, also compare Can our technical team maintain the system after source-code handover?; the linked guidance adds context that should be considered in the same decision.

Three ownership models

Model	Account and infrastructure	Advantage	Main risk	Recommendation
Client public-cloud account	Client master account with supplier subaccounts	Clear assets and billing; easier migration	Client owns account security and cost administration	Default for most custom projects
Client data centre or private cloud	Client hardware and network	Strongest direct boundary and can operate offline	Higher deployment, capacity, backup, and operations needs	Regulated or isolated networks
Provider-managed environment	Provider account or platform	Faster start and less client operation	Greater dependency for accounts, migration, cost, and exit	Contract must guarantee export and an exit process

Hybrid designs are common: a core database stays inside the client network while public entry points and static assets run in cloud services. The important artifact is a data-flow and responsibility map for business records, files, logs, search indexes, caches, queues, and backups, marking personal information and trade secrets.

Assets required for an independent handover

Asset	Handover requirement
Accounts and access	Ownership and administrators for cloud, domain, certificates, app stores, payments, SMS, and email
Source and versions	Full repositories, branches and tags, lockfiles, build instructions, third-party licences
Data and files	Database schema and dictionary, complete export, object-storage structure, documented formats
Configuration and secrets	Environment inventory, secret location, and rotation method without exposing values in ordinary documents
Deployment and operations	Architecture, pipeline, images, start/stop, monitoring, backup, recovery, and rollback guide
External integration	API documentation, callbacks, test and production accounts, quotas, and provider contact

A backup file is insufficient until it has been restored in an independent environment with recovery time and gaps recorded. Source alone also cannot run without databases, object files, secrets, and external accounts. Data exports should use documented or agreed formats and state how large files, increments, and downtime are handled.

Contract and operating practice

The contract defines data and code ownership, provider purpose and access, authorized personnel, retention, backup, export frequency, exit assistance, fees, deletion evidence, and remedies. The client retains at least two administrators; developers receive least privilege and lose access when their role or project ends. Production material is sanitized before test use, and logs and monitoring belong in the data inventory.

Run a portability exercise before final payment: a person who did not build the system follows the documentation to start a test environment, restore sanitized data, and execute the core workflow. This exposes missing scripts and tacit knowledge before a team change becomes urgent.

During replacement, control changes, export code, data, and the asset register, rotate former credentials, and have the new team restore and verify in isolation. An online service also needs cutover, incremental synchronization, downtime, and rollback planning; handing over a compressed database is not a migration.

Wavesteam prefers client ownership of production cloud, domain, and third-party master accounts and documents source, data, and deployment assets under our Transparent Delivery Standard. If a client selects managed hosting, the contract states export and migration boundaries rather than leaving “the data belongs to you” as a verbal promise.

References

• The NIST Cloud Computing Standards Roadmap provides context on cloud interoperability, portability, and standardization.
• The Twelve-Factor App: Config explains separating deployment configuration from code.
• The Wavesteam Transparent Delivery Standard describes our public asset and handover boundaries.

Data ownership and migration responsibility are ultimately evidenced by the contract, actual control of accounts, and a successful recovery test together.