Your Software Vendor Owns the Hosting, Domain, Database, and Code - Is That a Problem?

Your Software Vendor Owns the Hosting, Domain, Database, and Code—Is That a Problem?

A business has paid the same software company for five years to build and operate a customer portal.

The portal works.

Customers use it every day. The development company maintains the application, deploys updates, pays the cloud bill, manages the database, renews the domain, watches the monitoring dashboard, and keeps the code in its own repository.

Then the business asks a second company to perform a security review.

“Can you give us repository access?”

No.

“Can you give us cloud access?”

No.

“Who controls the domain?”

The original developer.

“Can you export the production database?”

Nobody inside the company knows.

“Where are the backups?”

The vendor handles them.

Potentially, this is a problem—but vendor management is not the same as harmful vendor dependency.

The concern becomes significant when the business cannot independently access critical systems, recover administrator access, export its data, obtain source code it is contractually entitled to, restore the application, remove former vendor access, or continue operating with another qualified provider.

The real test is not “Who manages it today?” The real test is “What happens tomorrow if that relationship ends?”

This article provides operational and technical guidance, not legal advice. Contract terms and applicable law determine actual intellectual-property, licensing, data, and ownership rights. Important software agreements should be reviewed by qualified counsel.

“Own” Can Mean Five Different Things

A surprising amount of confusion starts because everyone uses the word ownership to describe different things.

Legal ownership

This concerns copyright, intellectual property, contractual assignments, and licenses.

Under U.S. copyright law, copyright initially vests in the author unless another legal rule applies, such as a qualifying work made for hire. Transfers of copyright ownership generally require a signed writing. Ownership of a physical or digital copy is also distinct from copyright ownership. 

Paying for software therefore does not, by itself, settle every copyright question.

Account ownership

This asks whose organization controls the account.

Examples include:

•  Domain registrar account 
•  AWS organization 
•  Azure subscription 
•  Google Cloud organization 
•  GitHub organization 
•  Monitoring platform 
•  Payment processor 

Account ownership often determines who can recover access or remove other administrators.

Administrative control

An account may belong to the business while a vendor has broad administrative permissions.

That can be completely reasonable.

Cloud providers themselves encourage role-based and least-privilege access instead of giving every administrator unrestricted top-level credentials. AWS recommends protecting root access, using temporary credentials and roles for routine work, and restricting recovery mechanisms. Microsoft similarly recommends assigning only the permissions people need. 

Data control

Who can:

•  Export the data? 
•  Restore it? 
•  Delete it? 
•  Retain it? 
•  Access historical copies? 
•  Recover attachments? 

That may differ from who operates the database server.

Operational knowledge

Finally, who actually knows how the application works?

A company might possess the source code, cloud account, and database while still being heavily dependent on one engineer because nobody else understands deployment, integrations, recovery, or critical business rules.

That is knowledge lock-in.

Ownership, Access, and Portability Are Different

Ownership

This concerns who legally owns an asset or who controls the account in which it exists.

Ownership may come from law, registration, contract, assignment, or platform account structure.

Access

Access means someone can enter or administer the system.

A developer may have administrator access without owning the account.

A client may have read access to source code without having repository-administration rights.

Portability

Portability asks a more practical question:

Can the system actually be moved?

You may legally own code that relies on a proprietary vendor platform.

You may have a database export but no documentation explaining relationships among the records.

You may control the domain while lacking the credentials needed to deploy the application behind it.

Healthy software governance considers all three.

The Domain Name

A company's primary domain often connects far more than its public website.

It may affect:

•  Application URLs 
•  Employee email 
•  Password resets 
•  API endpoints 
•  Subdomains 
•  DNS 
•  TLS certificates 
•  Customer trust 

ICANN distinguishes the registered name holder from the registrar and uses authorization codes as part of transferring qualifying domains between registrars. Registrants should understand who can obtain the transfer authorization code and who controls the account used for transfer and recovery. 

For a business-critical domain, it is generally prudent to have clear company-controlled registration and recovery arrangements.

Verify:

•  Registrar 
•  Registered-name holder 
•  Renewal billing 
•  Recovery email 
•  Recovery phone 
•  MFA 
•  Domain lock 
•  Transfer process 
•  Authorization-code access 

A web developer can still manage DNS or technical settings without becoming the only person capable of recovering the domain.

DNS

Domain registration and DNS management are related, but they are not identical.

The registrar might be one provider while DNS is hosted somewhere else.

DNS can control:

•  Website routing 
•  Application routing 
•  Email delivery 
•  Verification records 
•  API endpoints 
•  Customer subdomains 
•  Certificate validation 

The business should know which provider hosts DNS, who has administrative access, how recovery works, and where the current records are documented.

A domain you technically control can still become difficult to operate if nobody can reconstruct the DNS zone.

Cloud Hosting

There are several perfectly legitimate models.

Business-Owned Cloud Account

Control

The organization controls the primary AWS, Azure, Google Cloud, or equivalent account structure and billing relationship.

Vendor access

The development company receives the permissions necessary to operate the application.

Main advantage

The provider can usually be removed without first recovering ownership of the entire cloud environment.

Main consideration

The business still needs competent security, billing, identity, and recovery governance.

AWS recommends keeping root credentials highly protected and using administrative identities or roles rather than root credentials for normal operations. Its guidance also recommends business-managed email arrangements and protected recovery mechanisms. 

Azure similarly separates highly privileged ownership from routine role-based administration. 

Vendor-Owned Dedicated Account

The vendor may create and operate an account dedicated to one customer.

That is not automatically a bad arrangement.

Ask:

•  Can the environment be transferred? 
•  If not, can it be recreated elsewhere? 
•  Who owns the data? 
•  Who controls backups? 
•  Who pays the provider? 
•  What happens at termination? 
•  Which credentials can be replaced? 

Shared Vendor Platform

A managed provider may operate several clients on shared infrastructure.

Direct transfer of the underlying cloud account may be impossible or inappropriate.

In that case, portability should focus on the parts that matter:

•  Application code 
•  Business data 
•  Files 
•  Configuration 
•  Domain 
•  Identity 
•  Documentation 
•  Migration procedures 

The important point is transparency.

Top-Level Cloud Recovery Matters

A business does not need every employee—or every developer—to possess root-level credentials.

In fact, that would usually be poor security practice.

What the organization should understand is:

•  Which identity controls account recovery 
•  Which email receives provider notices 
•  Which phone or MFA methods are registered 
•  Who receives billing alerts 
•  Who can create administrators 
•  Who can revoke vendor access 

The business needs resilient control above ordinary day-to-day vendor permissions.

Google Cloud similarly organizes resources around organization, IAM, projects, and billing accounts, allowing control to be separated across roles and resource hierarchy. 

The Source-Code Repository

Receiving a ZIP archive of source code is not the same thing as controlling the working repository.

There are several levels:

•  Offline copy 
•  Read access 
•  Write access 
•  Maintainer access 
•  Repository administrator 
•  Organization owner 

A repository may also contain:

•  Git history 
•  Branches 
•  Release tags 
•  Pull requests 
•  CI/CD definitions 
•  Security settings 
•  Deployment hooks 
•  Issue history 

GitHub supports granular repository roles and separate organization ownership. GitHub also recommends more than one organization owner so a project does not become inaccessible when a single owner becomes unavailable. 

A healthy model may therefore be:

Business: controls an organization or has agreed administrative continuity.

Vendor: receives appropriate engineering access.

Security: access can be reviewed and removed without deleting the repository.

That model is useful, but it is not an absolute requirement for every engagement.

Source-Code Access Is Not Copyright Ownership

This distinction deserves special attention.

You can possess the complete source tree without owning the copyright.

You can own copyright while a development provider still retains copies it is contractually permitted to retain.

You can own newly created project code while relying on pre-existing vendor libraries or open-source components that remain subject to their own licenses.

Questions that belong in legal review include:

•  Who authored the code? 
•  Which code existed before the project? 
•  Was any copyright assigned? 
•  What license rights were granted? 
•  Which components are third-party? 
•  Which are open source? 
•  What happens after termination? 

Under U.S. law, copyright ownership and transfers have specific rules. Commissioning and paying for work do not automatically make every work a “work made for hire,” and copyright transfers generally require a written instrument signed by the rights owner. 

Contract terms and applicable law determine the actual legal rights of the parties. Businesses should have qualified counsel review important software-development agreements.

What Should the Software Contract Clarify?

A well-drafted agreement may address:

•  Newly developed code 
•  Pre-existing vendor IP 
•  Open-source components 
•  Third-party software 
•  Licenses 
•  Source-code access 
•  Repository access 
•  Documentation 
•  Hosting 
•  Business data 
•  Data export 
•  Backups 
•  Domain and DNS 
•  Credentials 
•  Security responsibilities 
•  Subcontractors 
•  Termination 
•  Transition assistance 
•  Continuing licenses after termination 

The precise wording belongs with qualified legal counsel.

A technical team can identify the operational questions. Counsel should determine how the parties' rights are documented.

“Who Owns the Database?” Is Too Vague

That phrase can refer to at least four things.

Database infrastructure

This is the server or managed cloud service running PostgreSQL, MySQL, SQL Server, or another database system.

Database software

The engine may be open source, commercially licensed, or delivered as a managed service.

Database schema

This is the application-specific structure: tables, relationships, indexes, migrations, and constraints.

Business data

This includes customers, transactions, documents, configuration, history, and other records stored by the application.

These should not be treated as one ownership question.

A company could own its business data while using PostgreSQL on a vendor-managed cloud database.

Data Rights Are Not Enough Without Data Portability

Suppose the contract says:

The customer owns all customer data.

Good.

Now ask:

How do you get it out?

A useful export may need to preserve:

•  Relationships 
•  Attachments 
•  User identities 
•  Audit history 
•  Timestamps 
•  Configuration 
•  Reference data 
•  File metadata 

A CSV containing five obvious fields may not be enough to reconstruct the system.

Data portability is more than downloading a CSV.

The migration test is whether another qualified team could understand the exported information and reconstruct the required business processes.

Backups

Ask basic operational questions:

•  Where are backups stored? 
•  Who can access them? 
•  What is backed up? 
•  How frequently? 
•  How long are backups retained? 
•  Are they encrypted? 
•  Are encryption keys recoverable? 
•  Has a restore actually been tested? 
•  Can required copies be provided during transition? 

A backup that has never been restored should not automatically be treated as proven recovery capability.

SimplyRem's legacy-modernization guidance likewise emphasizes verifying backups and testing recovery before major changes to an existing production application. 

File and Object Storage

A database export may not contain everything.

Customer applications frequently store separate:

•  PDFs 
•  Photos 
•  Attachments 
•  Generated reports 
•  Scanned documents 
•  Media 
•  Archives 

An exit plan needs to account for those objects, their identifiers, access permissions, and relationships to database records.

Email and SMS Accounts

Applications often depend on messaging services for:

•  Password resets 
•  Verification 
•  MFA codes 
•  Notifications 
•  Customer messages 
•  Operational alerts 

Ask:

•  Who owns the provider account? 
•  Who controls sending domains? 
•  Who owns templates? 
•  Can another team issue new credentials? 
•  Does historical configuration matter? 
•  What happens to sender reputation during migration? 

Payment Accounts

Payment processing deserves especially clear separation.

The software vendor may implement the integration without needing to control the merchant relationship itself.

Distinguish:

•  Payment-provider account 
•  Application integration 
•  API credentials 
•  Transaction records 
•  Settlement account 

Changing a developer should not casually change where business funds settle.

This is an operational distinction, not financial advice.

Identity and Authentication

The application may depend on:

•  Microsoft Entra ID 
•  Google identity 
•  A third-party authentication service 
•  Social login 
•  SSO 
•  Custom authentication 

Ask:

Can the business still add administrators, revoke vendor users, reset access, change configuration, and keep users signing in when the development relationship ends?

Authentication is frequently one of the least convenient systems to discover is vendor-dependent during an emergency.

CI/CD and Deployment

Owning the source code is not enough if nobody else can release it.

A deployment process may depend on:

•  GitHub Actions 
•  GitLab CI 
•  Build systems 
•  Container registries 
•  Cloud roles 
•  Environment variables 
•  Database migrations 
•  Deployment approvals 
•  Signing keys 

Ask:

•  Where is the pipeline defined? 
•  Is it version controlled? 
•  Who can trigger production? 
•  Who owns the secrets? 
•  Can another provider deploy? 

SimplyRem currently publishes CI/CD, infrastructure-as-code, rollback, observability, and cloud-migration capabilities as part of its Cloud & DevOps practice. 

Secrets and Credentials

Critical credentials include:

•  API keys 
•  Database passwords 
•  Cloud credentials 
•  Payment secrets 
•  Email keys 
•  SSH keys 
•  OAuth secrets 
•  Certificates 

They should not depend solely on one developer's laptop, email inbox, or personal password manager.

OWASP recommends centralized secrets management, limiting access, logging important administrative activity, documenting stored secrets, and supporting rotation and revocation. 

The goal is not to hand every secret to every executive.

The goal is to make access controlled, recoverable, auditable, and transferable when necessary.

Monitoring and Error Tracking

A vendor transition becomes riskier when the incoming team loses visibility into application health.

Ask:

•  Where are dashboards? 
•  Who receives alerts? 
•  Are alert rules documented? 
•  Is historical telemetry important? 
•  Can another provider see production health? 
•  Which workflows are being monitored? 

SimplyRem's current monitoring guidance emphasizes application, infrastructure, database, dependency, and business-workflow health rather than simple homepage uptime. 

Third-Party SaaS Accounts

Modern applications may depend on services for:

•  Search 
•  Mapping 
•  AI APIs 
•  File scanning 
•  Electronic signatures 
•  Support 
•  Storage 
•  CAPTCHA 
•  Analytics 
•  Monitoring 
•  Notifications 

Do not assume every provider account can simply be transferred.

Some may support ownership changes.

Some require new accounts and credentials.

Some contain historical data that may not move.

Document the dependency before the termination conversation begins.

When Is Vendor Control Actually a Problem?

Healthy

The vendor operates much of the environment, but:

•  Contractual rights are clear. 
•  Business-critical recovery is understood. 
•  Appropriate administrator access exists. 
•  Data export has been tested. 
•  Backups are restorable. 
•  Infrastructure is documented. 
•  Vendor access is role based. 
•  Credentials can be rotated. 
•  Another qualified team could take over. 

This is managed outsourcing without unnecessary dependency.

Caution

The system works, but:

•  The vendor controls several important accounts. 
•  The business has normal access but not recovery control. 
•  Documentation is incomplete. 
•  Repository ownership is unclear. 
•  Backups exist but have never been restored. 
•  Data export has never been tested. 
•  Contract language is unclear. 

These conditions deserve clarification, not panic.

High Risk

Concern increases when several of these conditions exist:

•  No usable source-code access 
•  Domain registered to one individual's personal account 
•  Cloud recovery tied to a vendor employee 
•  No independent account recovery 
•  Unknown backup location 
•  No viable data export 
•  Only one person understands deployment 
•  No architecture documentation 
•  Credentials cannot be rotated 
•  Critical services belong to unknown accounts 
•  Business continuity requires the vendor's personal cooperation 

One finding does not automatically prove misconduct.

Together, they may demonstrate serious operational dependency.

What Is Software Vendor Lock-In?

Vendor lock-in exists when changing providers becomes difficult, expensive, or risky because of dependencies on:

•  Technology 
•  Accounts 
•  Data formats 
•  Licensing 
•  Architecture 
•  Documentation 
•  Infrastructure 
•  Contract terms 
•  Integrations 
•  Institutional knowledge 

Some lock-in is intentional.

Choosing AWS, Azure, Google Cloud, a managed database, or a commercial API creates some provider dependency in exchange for capabilities and reduced operational burden.

The meaningful distinction is:

Known dependency versus accidental dependency.

Technical lock-in

Proprietary frameworks, undocumented software, closed APIs, private packages, or vendor-only tooling make replacement difficult.

Operational lock-in

Only the vendor has cloud access, deployment credentials, runbooks, or monitoring.

Data lock-in

Data exists in proprietary formats, exports are incomplete, or attachments and metadata cannot be reconstructed.

Contractual lock-in

Termination, licensing, transition, IP, and export provisions may influence how difficult changing suppliers becomes.

Contracts require legal interpretation.

Knowledge lock-in

The company technically possesses everything, but nobody except the original provider understands it.

Documentation is therefore an operational control.

What Should a Business Control?

A useful default is not “the client owns absolutely everything.”

It is:

The organization should have enough legal, account, administrative, data, and recovery control to preserve continuity.

For example, a business may control the primary cloud organization, billing, domain, repository organization, recovery addresses, and important SaaS accounts while giving a development partner broad engineering access.

AWS, Microsoft, GitHub, and Google Cloud all provide mechanisms for separating organizational control from day-to-day technical permissions. 

That is often a strong governance model.

It is not the only valid one.

When Vendor-Owned Hosting Is Reasonable

Vendor-owned hosting can make sense for:

•  Fully managed services 
•  Shared platforms 
•  SaaS products 
•  Small managed environments 
•  Temporary pilots 
•  Development environments 

Ask:

•  Is this arrangement explicit? 
•  What can be exported? 
•  What cannot be transferred? 
•  Are backups available? 
•  How does termination work? 
•  Which security responsibilities belong to whom? 
•  Which components must be recreated elsewhere? 

If both sides understand those answers, vendor-managed hosting may be perfectly reasonable.

What Happens If the Vendor Becomes Unavailable?

This is not about assuming the vendor will behave badly.

Companies change.

People leave.

Providers merge.

Key employees become unavailable.

Technology is discontinued.

A security incident may require immediate credential rotation.

The business-continuity question is:

Could the organization recover without one particular person or supplier?

That is essentially a bus-factor test.

Emergency Access

For critical systems, consider documented emergency access for:

•  Domain registrar 
•  DNS 
•  Cloud 
•  Repository 
•  Database 
•  Backups 
•  Identity 
•  Payment 
•  Monitoring 

Good emergency access does not mean broadly sharing passwords.

It may involve:

•  MFA 
•  Multiple authorized administrators 
•  Protected recovery addresses 
•  Break-glass procedures 
•  Audit logging 
•  Periodic testing 

AWS specifically recommends protecting root recovery mechanisms and designing resilience into root-account access instead of relying on a single person. GitHub recommends multiple organization owners for similar continuity reasons. 

Ask These Questions Before Signing

1.  Who controls the domain? 
2.  Who controls the cloud account? 
3.  Where will the repository live? 
4.  What source-code rights will we receive? 
5.  What remains vendor IP? 
6.  Which third-party and open-source licenses apply? 
7.  Who owns or controls business data? 
8.  How can data be exported? 
9.  Where are backups? 
10.  How are restores verified? 
11.  Who controls production credentials? 
12.  Which third-party accounts are required? 
13.  What documentation is delivered? 
14.  Can another qualified provider deploy the application? 
15.  What happens when the agreement ends? 
16.  Is transition assistance addressed? 
17.  Which systems cannot be transferred directly? 
18.  Which recurring expenses remain? 
19.  Who can revoke vendor access? 
20.  What happens if the provider becomes unavailable? 

NIST's Secure Software Development Framework explicitly notes that software acquirers can use secure-development practices to improve communication with suppliers during procurement and management. 

What a Professional Software Handoff May Include

Code

•  Repository access 
•  Production release tag 
•  Branch information 
•  Dependency files 
•  Build instructions 

Infrastructure

•  Cloud inventory 
•  DNS configuration 
•  Network topology 
•  Infrastructure as code 
•  Environment inventory 

Data

•  Database location 
•  Backup process 
•  Restore procedure 
•  File storage 
•  Data dictionary where useful 

Operations

•  Monitoring 
•  Alerts 
•  Logs 
•  Runbooks 
•  Incident contacts 

Security

•  Administrator inventory 
•  Credential-transfer process 
•  Secret locations 
•  Credential rotation 
•  Certificates 

Business

•  Third-party vendors 
•  Recurring services 
•  Licensing 
•  Renewal information 
•  Support responsibilities 

SimplyRem currently publishes that runbooks, architectural decision records, onboarding materials, and tests are part of its development process, and its Process page states that work is written for the next engineer and “built to be handed over.” 

Taking Over Vendor-Controlled Software

Discovering weak control does not mean the first response should be to revoke everyone, change DNS, and migrate production immediately.

Unless an active security or legal situation requires urgent intervention, a controlled transition is usually safer.

Step 1: Build the inventory

Record every important asset:

•  Domain 
•  Registrar 
•  DNS 
•  Hosting 
•  Cloud 
•  Repository 
•  Database 
•  Backups 
•  Storage 
•  Email 
•  SMS 
•  Payments 
•  Identity 
•  Monitoring 
•  Analytics 
•  Certificates 
•  APIs 
•  CI/CD 
•  Secrets 
•  Contracts 

For each one, record its current administrator, billing owner, recovery method, transferability, business purpose, and desired future state.

Step 2: Verify contractual rights

Have qualified counsel review the agreement where necessary.

Technical teams should not guess what ownership, assignment, licensing, or transition provisions legally mean.

Step 3: Establish independent access

Prioritize the most important assets first.

Depending on the architecture, that might be:

1.  Domain 
2.  Cloud 
3.  Repository 
4.  Database 
5.  Backups 
6.  DNS 
7.  Identity 
8.  Critical third parties 

Step 4: Verify recovery before changing production

Confirm the database, files, backup keys, and restore process before making irreversible changes.

Step 5: Document the system

Capture architecture, data, DNS, integrations, deployment, monitoring, dependencies, and scheduled jobs.

Do not place production secrets directly into ordinary documents.

Step 6: Establish organization-controlled accounts where appropriate

That may include cloud, registrar, repository, monitoring, analytics, messaging, or other critical services.

Step 7: Migrate gradually

Some assets transfer.

Some must be recreated.

Some require parallel operation.

Some require data migration.

Some cannot be transferred at all.

Do not assume one procedure works for every provider.

Step 8: Rotate credentials

After control changes, review passwords, keys, tokens, database credentials, SSH keys, certificates, deployment credentials, and recovery mechanisms.

OWASP recommends documented secret inventories, revocation, rotation, restricted visibility, and secure lifecycle management. 

Step 9: Test the actual application

Verify:

•  Login 
•  Customer workflows 
•  Payments 
•  Email 
•  Files 
•  APIs 
•  Integrations 
•  Scheduled jobs 
•  Monitoring 
•  Backups 
•  Administrative access 

Step 10: Remove obsolete access

Only after validation should unnecessary legacy accounts, credentials, integrations, or subscriptions be removed.

NIST CSF 2.0 frames cybersecurity as a continuing governance and risk-management activity, which fits this staged approach better than treating access transfer as a one-time password exchange. 

Healthy Independence Does Not Mean Hiring an Internal DevOps Department

A business can outsource nearly all technical work and remain resilient.

The business may retain control over:

•  Contracts 
•  Accounts 
•  Recovery 
•  Data 
•  Administrative authority 

while the provider manages:

•  Development 
•  Infrastructure 
•  Deployment 
•  Monitoring 
•  Security operations 
•  Backups 
•  Maintenance 

A useful analogy is hiring a property manager without necessarily transferring ownership of the property.

The legal relationships are different, but the operational principle is similar: management does not have to eliminate ultimate control.

Source-Code Escrow

Source-code escrow is an arrangement where an agreed third party holds software materials that may be released under specified conditions.

Those materials may include:

•  Source code 
•  Build instructions 
•  Dependencies 
•  Documentation 

It can be useful in some proprietary software arrangements.

It is not a universal continuity solution.

An escrow deposit might be outdated.

It might not contain infrastructure.

It might omit data.

It might omit secrets or dependencies.

Nobody receiving it may know how to run the system.

Release conditions can also become contractual questions.

Escrow arrangements should therefore be evaluated with legal and technical advisers.

Acquisition and Technical Due Diligence

During investment, acquisition, or other due diligence, reviewers may ask for clarity around:

•  IP rights 
•  Contractor agreements 
•  Source repositories 
•  Domains 
•  Cloud accounts 
•  Open-source software 
•  Data 
•  Licensing 
•  Security 
•  Dependencies 

There is no single universal diligence checklist.

But unclear ownership or inaccessible infrastructure can make a company's technical position harder to evaluate.

What a Healthy Vendor Relationship Looks Like

A good relationship can involve deep vendor access.

The difference is that access is intentional and governed.

Useful characteristics include:

•  Clear responsibilities 
•  Transparent accounts 
•  Role-based permissions 
•  Secure credential handling 
•  Portable business data 
•  Current documentation 
•  Tested recovery 
•  Defined offboarding 
•  Cooperative transition procedures 

SimplyRem currently describes its process as documented throughout development, explicitly says work is built for the next engineer, supports taking over inherited codebases, and publishes capabilities covering cloud infrastructure, CI/CD, application observability, migrations, source-code security review, and cloud-security assessment. 

The purpose of good governance is not to make replacing the vendor easy because you expect the relationship to fail. It is to ensure the business remains resilient regardless of personnel or provider changes.

Conclusion

Your software vendor managing the system is not necessarily the risk.

Losing the ability to control, recover, understand, or transfer the system is the risk.

A business should know:

•  Who controls each account 
•  Who has administrator access 
•  What the contract says 
•  Where the source code lives 
•  Where the data lives 
•  How backups work 
•  How deployment works 
•  Which third parties are involved 
•  How credentials are recovered 
•  Whether another qualified provider could take over 

The strongest vendor relationships do not depend on making the client helpless.

They make sophisticated outsourcing possible while preserving business continuity.

Five Types of Control

Legal Ownership

Meaning: Copyright, contractual IP rights, assignment, or licensing.

Verify: What the agreement says and what applicable law provides.

Important: Possessing code and owning copyright are different questions. 

Account Ownership

Meaning: Which organization or identity controls the registrar, cloud, repository, or SaaS account.

Verify: Top-level administrators, billing, MFA, and recovery.

Administrative Control

Meaning: Who can configure or operate the service.

Verify: Roles, privileges, access expiration, and removal procedures.

Data Control

Meaning: Ability to access, export, restore, retain, or delete company data.

Verify: Data format, files, backups, retention, and migration process.

Operational Knowledge

Meaning: Ability to deploy, troubleshoot, restore, and maintain the system.

Verify: Architecture documentation, runbooks, deployment procedures, dependency inventory, and support knowledge.

Domain-Control Card

Primary Domain

Recommended control:
Business-critical domains generally benefit from company-controlled registration and recovery arrangements.

What the vendor may manage:
DNS configuration, certificate setup, technical records, migrations, and troubleshooting.

Minimum business access:
Ability to recover the registrar account, renew the domain, confirm the registrant, and initiate an appropriate transfer where permitted.

Questions to verify:
Who is the registrant? Which email receives recovery messages? Who has MFA? Who can obtain the authorization code?

Main transition risk:
Losing control can affect web, application, email, DNS, and authentication services. ICANN documents authorization-code and transfer procedures for eligible gTLDs. 

DNS-Control Card

DNS

Recommended control:
The company should know the provider, administrators, recovery process, and current records.

What the vendor may manage:
Routine records, routing, verification, mail records, API subdomains, and certificate validation.

Minimum business access:
Appropriate administrative or recovery access.

Questions to verify:
Where is DNS hosted? Is the zone documented? Can the company change or recover it?

Main transition risk:
A vendor change can unintentionally interrupt the website, application, email, APIs, or certificates.

Cloud-Account-Control Card

Cloud Account

Recommended control:
For dedicated production environments, organization-controlled billing and recovery is often a strong model.

What the vendor may manage:
Infrastructure, deployments, networking, databases, monitoring, and routine administration.

Minimum business access:
Top-level recovery or appropriately resilient owner/admin access.

Questions to verify:
Who owns the recovery email? Who receives bills? Who can create or remove administrators?

Main transition risk:
The company may possess code and data yet lack practical ability to operate the production infrastructure. AWS and Microsoft both recommend strong separation between highly privileged control and normal day-to-day permissions. 

Source-Code-Control Card

Source Code

Recommended control:
The business should understand exactly what source-code access and rights its contract provides.

What the vendor may manage:
Development, branching, review, releases, and maintenance.

Minimum business access:
The access agreed in the contract and enough operational availability to support continuity.

Questions to verify:
Is all production code available? Which code is pre-existing vendor IP? Which dependencies are third-party?

Main transition risk:
The company receives an incomplete archive or discovers that important components are not included.

Repository-Control Card

Source Repository

Recommended control:
Use an organizational structure with documented administrative continuity.

What the vendor may manage:
Commits, pull requests, branches, issues, release tags, CI configuration, and routine repository settings.

Minimum business access:
Appropriate administrative visibility and continuity.

Questions to verify:
Who owns the organization? Are there multiple administrators? Can vendor access be removed without moving the repository?

Main transition risk:
Code may remain technically available while history, CI/CD, or administrative control is lost. GitHub supports granular repository roles and recommends multiple organization owners. 

Database-and-Data-Control Card

Database and Business Data

Recommended control:
Treat infrastructure, database software, schema, and business data as separate concerns.

What the vendor may manage:
Database operations, migrations, performance, backups, and maintenance.

Minimum business access:
Documented and testable export and recovery procedures.

Questions to verify:
Can all required records, files, relationships, history, and configuration be migrated?

Main transition risk:
A database dump exists but cannot meaningfully recreate the working application.

Backup-Control Card

Backups

Recommended control:
Recovery responsibilities should be documented and tested.

What the vendor may manage:
Schedules, encryption, retention, replication, restore testing, and monitoring.

Minimum business access:
Knowledge of where backups live and a viable process for obtaining or restoring required data.

Questions to verify:
Does the backup include files? Who controls encryption keys? When was restoration last tested?

Main transition risk:
The organization discovers during migration or an incident that the backup is incomplete or unusable.

Third-Party-Account-Control Cards

Payment Provider

Recommended control:
The merchant relationship and settlement configuration should be clearly assigned.

Vendor may manage:
Integration and technical credentials.

Main risk:
A developer change unintentionally affects payment operations.

Email and SMS

Recommended control:
Document account ownership, sending domains, credentials, templates, and migration requirements.

Vendor may manage:
Delivery configuration and application integration.

Main risk:
Password resets and operational notifications stop during transition.

Identity Provider

Recommended control:
The organization should retain resilient administrator and recovery capability.

Vendor may manage:
Application configuration and integrations.

Main risk:
Users cannot sign in after provider access changes.

Analytics

Recommended control:
Prefer durable organization-controlled access for important historical analytics.

Vendor may manage:
Instrumentation and reporting.

Main risk:
Historical visibility disappears when an agency account is removed.

Monitoring

Recommended control:
Ensure dashboards, alert rules, and operational knowledge are transferable or reproducible.

Vendor may manage:
Instrumentation, alerts, dashboards, and incident response.

Main risk:
The new team loses production visibility during the riskiest period of the transition.

Other APIs

Recommended control:
Record ownership, credentials, billing, data, and portability for each dependency.

Vendor may manage:
Implementation and technical operation.

Main risk:
The application depends on a service that cannot be transferred and must be migrated or reconfigured.

Healthy / Caution / High Risk Ownership Assessment

Healthy

•  Rights and responsibilities are documented. 
•  Business recovery is available. 
•  Vendor permissions are role based. 
•  Data exports work. 
•  Backups are tested. 
•  Documentation is current. 
•  Another qualified team could take over. 

Caution

•  Vendor controls multiple accounts. 
•  Recovery ownership is unclear. 
•  Exports have not been tested. 
•  Documentation is incomplete. 
•  Repository administration is ambiguous. 
•  Backups are vendor-only. 
•  Contract terminology needs review. 

Action: Clarify first. Do not assume misconduct.

High Risk

•  No independent source access 
•  No independent domain recovery 
•  Cloud tied to an individual's email 
•  Unknown backup location 
•  No usable data export 
•  No deployment documentation 
•  Credentials cannot be rotated 
•  Another provider cannot operate the system 

Action: Perform technical, contractual, security, and continuity review before making disruptive changes.

Mobile-First Asset-Control Guide

Primary Domain

Recommended control: Company-level recovery.

What vendor may manage: Technical DNS and certificates.

Minimum business access: Registrar recovery and renewal.

Main transition risk: Loss of public identity and routing.

DNS

Recommended control: Documented provider and recovery.

What vendor may manage: Records.

Minimum business access: Administrative recovery.

Main transition risk: Service interruption.

Cloud Organization

Recommended control: Resilient top-level business recovery where practical.

What vendor may manage: Infrastructure.

Minimum business access: Ability to change administrators.

Main transition risk: Production cannot be independently operated.

Repository

Recommended control: Durable organizational access.

What vendor may manage: Development workflow.

Minimum business access: Agreed code and administrative visibility.

Main transition risk: Code history and deployment tooling become inaccessible.

Production Database

Recommended control: Documented data and recovery rights.

What vendor may manage: Operations.

Minimum business access: Tested export/restore process.

Main transition risk: Data cannot be moved.

Backups

Recommended control: Documented and tested recovery.

What vendor may manage: Backup operations.

Minimum business access: Ability to obtain or restore required copies.

Main transition risk: Recovery plan exists only on paper.

File Storage

Recommended control: Included in data portability plan.

What vendor may manage: Object storage.

Minimum business access: Export path.

Main transition risk: Files are missing from database-only migration.

Identity Provider

Recommended control: Business recovery authority.

What vendor may manage: Application integration.

Minimum business access: Administrator continuity.

Main transition risk: Users lose access.

Payment Account

Recommended control: Clearly documented merchant relationship.

What vendor may manage: Integration.

Minimum business access: Account administration appropriate to the business.

Main transition risk: Payment or settlement disruption.

Email/SMS

Recommended control: Durable account and domain arrangements.

What vendor may manage: Technical sending.

Minimum business access: Credential replacement and provider visibility.

Main transition risk: Authentication and notifications fail.

Analytics

Recommended control: Organization-level access.

What vendor may manage: Instrumentation.

Minimum business access: Historical reporting access.

Main transition risk: Data history disappears.

Monitoring

Recommended control: Transferable/reproducible operational visibility.

What vendor may manage: Alerts and dashboards.

Minimum business access: Visibility into health.

Main transition risk: Blind migration.

CI/CD

Recommended control: Documented, version-controlled pipeline.

What vendor may manage: Releases.

Minimum business access: Ability for another qualified team to deploy.

Main transition risk: Code cannot be released.

Secrets

Recommended control: Secure organizational secret-management process.

What vendor may manage: Required production secrets.

Minimum business access: Recovery and rotation procedures.

Main transition risk: One person's credentials become a single point of failure.

Third-Party APIs

Recommended control: Document every dependency.

What vendor may manage: Integration.

Minimum business access: Billing, credential, and migration clarity.

Main transition risk: Hidden provider dependency.

Software Vendor Exit Test

•  Who controls the domain? 
•  Who can renew it? 
•  Who controls DNS? 
•  Who controls the cloud? 
•  Who receives cloud billing? 
•  Where is the source code? 
•  Who administers the repository? 
•  What does the contract say about IP? 
•  Where is the production database? 
•  Can the data be exported? 
•  Where are uploaded files? 
•  Where are backups? 
•  Has restore been tested? 
•  Who controls authentication? 
•  Who controls payment accounts? 
•  Who controls monitoring? 
•  How is production deployed? 
•  Can credentials be rotated? 
•  Can another qualified provider operate the system? 
•  Is transition documentation current? 

If the answer to several of these questions is “we don't know,” the organization has a governance problem worth addressing before an emergency forces the issue.

 Asset Inventory Checklist

For every asset, document:

•  Asset name 
•  Business purpose 
•  Current provider 
•  Account owner 
•  Administrators 
•  Billing owner 
•  Recovery email 
•  Recovery phone/MFA 
•  Data stored 
•  Credential location 
•  Backup status 
•  Export method 
•  Transferability 
•  Dependencies 
•  Main transition risk 
•  Desired future state 
•  Last verified date 

Software Handoff Checklist

Code

•  Repository 
•  Branches 
•  Production tag 
•  Dependencies 
•  Build instructions 

Infrastructure

•  Cloud inventory 
•  DNS 
•  Networking 
•  Infrastructure as code 
•  Environment inventory 

Data

•  Database 
•  File storage 
•  Backup process 
•  Restore procedure 
•  Data-model documentation where appropriate 

Operations

•  Monitoring 
•  Alerts 
•  Logs 
•  Runbooks 
•  Incident contacts 

Security

•  Administrator list 
•  Secret-transfer process 
•  Credential rotation 
•  Certificates 
•  Temporary access review 

Business

•  Vendor list 
•  Recurring subscriptions 
•  Renewal dates 
•  Licensing 
•  Support responsibilities 

Emergency-Access Checklist

•  Domain registrar recovery 
•  DNS emergency access 
•  Cloud recovery 
•  Repository ownership continuity 
•  Database recovery 
•  Backup access 
•  Identity-provider administration 
•  Payment-provider administration 
•  Monitoring access 
•  Multiple authorized individuals 
•  MFA 
•  Break-glass procedure 
•  Access logging 
•  Periodic recovery test 

New-Vendor Due-Diligence Checklist

•  Who controls the domain? 
•  Who controls cloud billing? 
•  Where does source code live? 
•  What repository access does the client receive? 
•  What does the agreement say about newly created code? 
•  What remains vendor IP? 
•  Which third-party licenses apply? 
•  Who controls business data? 
•  How does data export work? 
•  How are backups handled? 
•  Are restores tested? 
•  Who controls production secrets? 
•  Who controls third-party services? 
•  How is vendor access revoked? 
•  What documentation is delivered? 
•  Can another team deploy the application? 
•  What happens on termination? 
•  Is transition support addressed? 
•  Which dependencies are difficult to move? 

Existing-Vendor Assessment Checklist

•  Repository is current. 
•  Production release is identifiable. 
•  Infrastructure is documented. 
•  Cloud administrators are known. 
•  Domain recovery is known. 
•  DNS records are documented. 
•  Database location is known. 
•  Data export has been tested. 
•  Backups are current. 
•  Restore has been tested. 
•  File storage is included. 
•  Third-party services are inventoried. 
•  Credentials are centrally managed. 
•  Deployment is repeatable. 
•  Monitoring is accessible. 
•  Dependencies are documented. 
•  Licensing is documented. 
•  Vendor access can be revoked. 
•  Transition responsibilities are understood. 

Provider Transition Process

1.  Inventory all critical technology assets. 
2.  Have qualified counsel review relevant contractual rights. 
3.  Establish independent access in risk-priority order. 
4.  Verify backups and perform a safe restore test. 
5.  Document architecture, dependencies, integrations, and deployment. 
6.  Create organization-controlled accounts where appropriate. 
7.  Determine which services transfer and which require recreation. 
8.  Migrate incrementally. 
9.  Rotate credentials through controlled change procedures. 
10.  Test core business workflows. 
11.  Verify monitoring and recovery. 
12.  Remove obsolete vendor access only after successful validation. 
13.  Update documentation, billing, and ownership records. 

SimplyRem's modernization guidance similarly favors dependency discovery, verified backups, incremental changes, observability, and rollback rather than an uncontrolled big-bang transition. 

Mobile-Friendly Ownership Decision Path

Question 1: Can your company independently access the asset?

No: Investigate account ownership and recovery.

Yes: Continue.

Question 2: Can the company change or remove vendor access?

No: Review top-level administrative control.

Yes: Continue.

Question 3: Can the asset be transferred, exported, or recreated?

No: Document the dependency and its business consequences.

Yes: Continue.

Question 4: Could another qualified provider operate it?

No: Identify missing documentation, credentials, source components, or proprietary dependencies.

Yes: Continue.

Question 5: Has recovery actually been tested?

No: Test it before treating the exit plan as reliable.

Yes: The arrangement has stronger operational resilience.

Possible outcomes:

• Healthy: Control and recovery are understood and tested. 
• Needs documentation: Access exists but knowledge is incomplete. 
• Needs transition planning: Portability is uncertain. 
• High dependency: Independent continuity is not currently practical. 

Red-Flag Cards

Domain Registered to a Developer Personally

Concern: A critical business asset depends on one individual's account.

Next question: Can the company independently recover or transfer it?

Cloud Root Account Tied to Vendor Email

Concern: Top-level recovery may depend on an outside organization.

Next question: Can company-controlled recovery be established without disrupting production?

Source Code Exists Only on Vendor Computers

Concern: Loss of the vendor could also mean loss of the working source tree and history.

Next question: Is there a current repository and verified backup?

No Written IP Provision

Concern: Legal rights may be unclear.

Next action: Have qualified counsel review the agreement.

No Database Export Procedure

Concern: Data ownership may exist on paper without practical portability.

Next question: Can a representative migration export be tested?

No Restore Testing

Concern: Backup existence is being confused with recovery capability.

Next action: Test a controlled restore.

Vendor Owns All Third-Party Accounts

Concern: Several hidden migrations may be required simultaneously.

Next question: Which services can transfer and which must be recreated?

No Architecture Documentation

Concern: Another team may need to reverse-engineer production before changing it.

Next action: Capture architecture and dependencies while current expertise is available.

No Credential Inventory

Concern: Important keys may survive offboarding or become impossible to rotate.

Next action: Inventory credentials without placing secrets in normal documentation.

Vendor Refuses Reasonable Transition Planning

Concern: Operational continuity may be difficult.

Next action: Review contractual rights, technical dependencies, and transition options carefully rather than assuming the reason.

Frequently Asked Questions

Should my software developer own my domain?

Usually, a business-critical domain should have clear company-controlled registration and recovery arrangements. A developer can still manage DNS and technical settings. The correct legal and contractual arrangement depends on the circumstances, but the company should understand who the registered name holder is, who can renew the domain, and who can obtain the credentials needed for a permitted transfer. ICANN documents registrar-transfer and authorization-code procedures. 

Should my software vendor own my hosting account?

It can be reasonable, depending on the service model. Dedicated production infrastructure is often easier to govern when the business retains top-level recovery or organizational control and delegates operational access to the vendor. Shared managed platforms may legitimately remain vendor-owned. The important questions are what is portable, who controls the data, how recovery works, and what happens at termination.

Who should own a GitHub repository for custom software?

There is no universal rule, but repository continuity should be explicit. A company-controlled organization with role-based vendor access is often a strong model because administrators can change without relocating the repository. GitHub supports granular repository roles and recommends multiple organization owners for continuity. Contractual source-code rights remain a separate legal question. 

Does paying for custom software mean I own the source code?

Not automatically. Payment does not by itself answer every copyright or licensing question. Under U.S. copyright law, copyright initially vests in the author unless another rule applies, and copyright transfers generally require signed written documentation. Work-made-for-hire rules also have specific requirements. Have qualified counsel review the agreement. 

What is the difference between source-code access and source-code ownership?

Access means you can obtain or work with the code; ownership concerns legal rights. A company may possess a complete repository but only have a license to some components. Conversely, it may own certain project code while a vendor still manages the repository. Repository administration, copyright, licensing, and operational possession should therefore be evaluated separately.

Who owns data stored in a custom application?

The answer depends on the contract, applicable law, and the type of data involved. Do not assume database infrastructure ownership and business-data ownership are the same issue. Agreements should address permitted vendor use, export, retention, deletion, backup, return on termination, and relevant subprocessors. Sensitive or regulated data warrants qualified legal and privacy review.

Should I have direct production database access?

Not necessarily. Giving every business user a production database password can create security and operational risk. More important is whether the organization has appropriate administrative continuity, a tested backup and restore process, documented data export, and a mechanism for another qualified operator to assume responsibility when required.

Should my company own the AWS, Azure, or Google Cloud account?

For a dedicated business production environment, organization-controlled top-level recovery is often a strong governance model, but it is not the only valid model. Vendors can receive delegated technical access. AWS, Microsoft, and Google Cloud all provide mechanisms for separating organization-level control from routine engineering permissions. 

Is vendor-managed hosting vendor lock-in?

Not automatically. Managed hosting becomes problematic when the customer does not understand its dependencies or lacks a workable exit path. A shared managed platform may intentionally remain vendor-controlled. What matters is whether required data, code, configuration, domain control, and operational knowledge can be transferred or recreated within an acceptable level of risk.

What happens if my developer goes out of business?

The impact depends on how much independent continuity your company already has. You should know who controls the domain, cloud, repository, data, backups, identity, payment services, deployment, and monitoring. Emergency recovery should be planned before it is needed, with MFA, multiple authorized people, and documented procedures rather than widely shared passwords.

What should be included in a software handoff?

A handoff should cover more than source code. Depending on the system, it may include repositories, build instructions, cloud architecture, infrastructure as code, DNS, databases, backups, files, integrations, monitoring, logs, runbooks, certificates, credential-transfer procedures, third-party vendors, licensing, and support responsibilities.

What is source-code escrow?

Source-code escrow is an arrangement where agreed software materials are held by a third party subject to specified release conditions. It may help in some proprietary-software relationships, but it does not guarantee continuity. Deposits may be outdated or may omit infrastructure, data, dependencies, credentials, or operational knowledge. Legal advice is appropriate when evaluating escrow terms.

How do I move custom software to another development company?

Treat the change as a technical migration, not merely a password exchange. Inventory assets, verify contractual rights, secure independent access, test backups, document architecture, identify non-transferable services, migrate incrementally, rotate credentials, test core workflows, confirm monitoring and recovery, and remove obsolete access only after validation.

How can a business reduce software vendor lock-in?

Make dependencies intentional and visible. Use documented accounts, role-based vendor access, portable data, maintainable source repositories, tested backups, reproducible deployment, secure secret management, and current architecture documentation. Some provider dependency can be a rational tradeoff; the objective is to avoid accidental dependency that prevents the company from operating or changing providers.

Can SimplyRem take over software developed by another vendor?

Yes. SimplyRem's current Web Application Development page explicitly states that it takes over inherited codebases and that discovery can include a code audit, dependency-risk report, and written remediation plan. Its published Process also emphasizes documentation and systems built for the next engineer. 

Final SimplyRem CTA

Your software vendor managing the system is not necessarily the risk.

Losing the ability to recover, understand, administer, export, or transfer the system is.

SimplyRem currently supports inherited web applications, codebase assessment, application modernization, Cloud & DevOps engineering, infrastructure as code, CI/CD, observability, cloud migration, source-code security review, cloud-security assessment, documentation, and ongoing stewardship. 

Unsure who actually controls your custom software, cloud infrastructure, source repository, domain, database, or backups? Contact SimplyRem to review the current environment, identify operational dependencies, document critical assets, and plan a controlled transition before those dependencies become an emergency. SimplyRem's current contact page also states that it works alongside existing internal teams and leaves runbooks, tests, and documentation for maintainability.