Summary

  • Fastly's versionless domains can be administered independently of a service version, allowing name preparation and application deployment to follow different schedules.
  • The ability to replace an operating team depends on DNS control, acceptable certificate proof, account authority and service or routing associations. Delivery of the application alone does not establish it.
  • Cross-account delegation is not the same as leaving Fastly. Classic domains and Platform TLS also have different procedures, limiting any claim that handover is universally self-service.

The address is not in the code repository

Consider an orderly change of website agency. The incoming team receives the application, understands the origin infrastructure and can reproduce the deployment. Nobody is refusing to cooperate. Yet one important question remains: can the customer arrange for the familiar public address to reach the new team's service without first reconstructing permissions held by the old team?

This is a hypothetical handover, not an account of a Fastly customer dispute. It exposes a distinction that outsourcing can obscure. Application work produces deliverables; operation of the public name requires continuing authority. A buyer can possess the first while depending on somebody else for the second. The distinction becomes commercially important when the buyer wants to change who does the work.

Fastly's domain documentation describes a feature that makes the separation explicit. A versionless domain is managed outside an individual service version. It can be added before it is associated with a service, and changes to the domain need not increment the service version. The public name becomes something that can be prepared and administered on its own schedule.

That is useful even when nobody intends to switch suppliers. A release team need not carry every name-administration task inside an application release. Another team can prepare a name before the receiving service is selected. But the same separation changes what counts as a complete handover: a signed-off deployment cannot also stand for all the authority that directs users towards it.

A transfer of administration, with conditions

The older arrangement helps explain the difference. Fastly calls domains attached to service configurations and their versions classic domains. Changing their service association requires a new version. The documentation limits classic functionality to accounts created before 16 September 2025. Where a classic domain is already used by another Fastly account, delegation to a different account goes through support.

Versionless domains have a documented self-service delegation path to another account or customer. Fastly describes two forms of proof: obtaining a Fastly-managed certificate through a DNS challenge and setting a DNS token, or supplying a valid publicly trusted certificate with its matching private key. These are conditions imposed by the product. They are not an instruction to circulate production private keys among contractors.

For a buyer, the useful change is narrower than effortless portability. An eligible handover need not necessarily begin with a support intervention. Where the customer retains appropriate permissions and can furnish the required proof, it has another way to rearrange administration. Where the departing operator controls those prerequisites, the existence of a self-service screen does not by itself give the customer access to it.

There is an important product exception. Fastly's versionless-domain guide says Platform TLS customers have read-only access to Unified Domain Management and must contact support to manage domains or migrate. Procurement cannot safely assume that a capability described for one account arrangement is available under every TLS product. Identifying the existing arrangement is part of establishing the handover's scope.

None of this establishes a fee, a promised completion time or a measured reduction in switching costs. The public sources do not disclose those things. The commercial inference is simply that separating the name from the release can make an operating relationship easier to replace, provided the customer has also retained the means to authorise that replacement.

Preparation can precede the movement of customers

The most useful freedom may be the ability to do part of the work early. Fastly's guide to managed certificates explains that its default ACME DNS challenge points the challenge subdomain to Fastly. It does not require production traffic to move at that moment. TLS preparation and the eventual traffic change can therefore be scheduled separately.

The alternative HTTP challenge has a different operational consequence: it directs traffic immediately. Fastly warns that incomplete TLS or service setup can then expose users to security warnings or an unavailable site. The distinction matters to an operating contract because unfinished work can either remain a preparatory task or become something customers encounter. A handover date cannot make those two situations equivalent.

Earlier preparation also changes the conversation between agencies. Missing permissions or proof can be identified while the old service is still carrying traffic, rather than first appearing as a request for urgent cooperation at the final change. That is an option to organise the work, not a guarantee of uninterrupted migration. The receiving service and its application behaviour still have to be ready.

Nor does successful preparation remove future dependencies. The managed-certificate guide identifies DNS changes and restrictive CAA settings as potential obstacles to renewal. The TLS subscriptions API separately describes issuance, renewal and retry states. Continuing retries are not evidence that an expired certificate remains valid. The relevant handover question is who will maintain the conditions for the next renewal, not only who obtained the current certificate.

The certificate's lifecycle can also differ from its use in serving traffic. Fastly documents that deactivating all TLS activations does not, by itself, stop managed renewal; deleting a subscription is a separate action. That distinction is not a proposed migration step. It demonstrates why a buyer needs a clear allocation of ongoing responsibility instead of treating every certificate-related action as part of one indivisible switch.

Proof of control is not title to the name

Fastly's domain management API keeps several conditions apart. A domain may be verified through qualifying certificate evidence; activation indicates at least one TLS activation. Its service association and routing-configuration association are separately represented and can be empty. These are descriptions of operational relationships, not a registry of legal ownership.

A certificate-based demonstration of control cannot settle a dispute over a registered name, establish ownership of a company or transfer rights in a brand. Equally, TLS activation does not establish that every business path reaches the intended application. The buying organisation needs to preserve these distinctions when it allocates responsibilities. The same person need not administer every part, but somebody must know which part a particular permission governs.

Self-managed certificates make the continuing obligations especially visible. Fastly's self-managed certificate guide requires a valid certificate and matching private key, with the relevant TLS configuration, activations and DNS arrangements. Several names appearing on a certificate do not mean that every intended name has automatically been explicitly activated. The customer also carries responsibility for renewing self-managed certificates.

A transferred certificate file is consequently a poor substitute for an operating arrangement. Renewal ownership, access and the intended activations all matter after the handover meeting ends. Fastly's TLS prerequisites add account and permission requirements. Moving documents between teams cannot be assumed to confer the authority that those documents describe.

The name can conceal more than one service

A public address need not lead to a single application service. Fastly's request-routing rules can direct requests to different Fastly services according to paths and conditions, without writing VCL or Compute code for that routing layer. This offers a way to divide work behind a stable name.

For example, an organisation could use different services for different parts of a website while keeping its public address familiar. This is an illustration of the documented capability, not a reported customer deployment. The advantage is an additional administrative choice about where requests go. The accompanying obligation is to hand over the rules that make that choice, not merely the applications receiving the requests.

The documented arrangement requires a domain in Domain Management, a valid TLS certificate and an active service. It also requires a default rule. A routing configuration must be deployed and linked to the domain; a deployed configuration begins routing when linked. Association with the public name is therefore a consequential authority of its own. An incoming operator can receive a perfectly usable service while a different team still controls which requests reach it.

The rules do not imply that Fastly is providing routing to another CDN. They divide requests among services inside Fastly. Buyers should resist describing every form of internal flexibility as an exit capability. Flexibility can be valuable while still stopping at the boundary of the supplier's own system.

Four moves that should not share one label

Changing a service association within an account, delegating a name across Fastly accounts, moving public traffic to another provider and changing legal ownership are different events. The first two concern administration inside Fastly. The third involves a receiving provider's service, certificates and application requirements as well as the external DNS arrangement. The fourth is not established by the product's technical proof.

Fastly's traffic-routing guide says it does not provide managed DNS in the setup being described. Customers choose a DNS provider and install the supplied records. That leaves an administrative surface outside the application release. Whether the customer itself can use it, however, depends on how the organisation has arranged accounts and delegated work.

DNS also has timing characteristics that a contractual handover cannot wish away. Previously cached records can continue to affect requests after a change. Conversely, changing a domain's service association inside Fastly is not automatically a public DNS migration. Keeping the events distinct prevents both an exaggerated claim of external portability and an underestimate of what an internal reassignment can change.

The scale of the business makes these small administrative distinctions worth examining. In its second-quarter 2026 results, Fastly reported revenue of $183.3 million, including $133.9 million from Network Services. These are company-reported measures of scale, not evidence of versionless-domain adoption or savings. They place the name-management function inside a substantial delivery business.

For buyers, the practical bargain is more specific than avoiding dependence on all suppliers. A business should be able to replace the team operating behind its public name without having to rediscover how it can authorise that change. Fastly provides tools for separating the name from a release. The buyer still has to arrange who can prove control, maintain the necessary conditions and appoint the next operator.