Before signing an ordering contract, verify who controls your domain and DNS, who maintains the security certificate, and what must happen to point your ordering subdomain to another provider. Get the answers in writing, including any notice periods, fees and support limits. A URL that contains your restaurantās name does not, by itself, give you control over where it leads.
For example, order.yourrestaurant.com is a subdomain of your main domain. It can provide a familiar address for guests while the ordering service behind it is supplied by another company. The important buying question is whether you can change that service without relying indefinitely on a departing vendor.
Use the questions below alongside the broader online ordering buying guide. They focus on the address and its exit path, not on choosing a name for it.
Identify the domain owner and DNS administrator
Start with two different accounts. Your domain registrar is where the domain is registered and renewed. Your DNS provider holds the records that tell browsers where to find services on that domain. One company may provide both services, but that is not always the case.
Ask whoever set up your restaurant website for the registrar name, the DNS provider name and the account contacts. Check that the restaurant has access through accounts it controls, rather than only through an employeeās personal email or a vendorās login. Store recovery details securely and give a second authorized person an appropriate way to regain access.
Then ask the ordering provider exactly what it needs to configure the subdomain. A provider may ask your DNS administrator to add a record that points the ordering address to its service. The record might be a CNAME or another type specified in the setup instructions. You do not need to hand over control of the whole domain just because a provider needs one record changed.
- Is the domain registered in the restaurantās account, and who receives renewal notices?
- Who can view and edit DNS records, and how does the restaurant recover access?
- Will the provider request a specific record change, or require broader account access? Why?
- Can the restaurant remove or replace the ordering record without the providerās permission?
- Will the ordering address use the restaurantās domain, or an address the provider controls?
If an agency manages DNS, agree on who will make changes and how quickly. Restaurant ownership of the domain is useful, but it will not help on a busy transition day if the only person with DNS access is unavailable. Ask for the handoff procedure as well as the login arrangement.
Check certificate and redirect responsibilities
A security certificate allows guests to use the HTTPS version of the ordering address without a certificate warning when it is configured correctly. Ask who obtains, renews and replaces the certificate for your subdomain. Also ask what access or domain verification each provider needs to issue one.
The timing matters. A new provider may need to verify control of the subdomain before its certificate can be ready. Ask whether that work can happen before the DNS change, what information it needs from your administrator, and how you can check readiness. Do not assume a certificate issued for your main website automatically covers a separate ordering service.
Redirects are a separate issue. A redirect sends a visitor from one URL to another. If guests follow an old link, someone must operate the address receiving that request for a redirect to work. Ask whether the departing provider offers redirects after cancellation, for how long, and at what cost. If it controls the old address, the restaurant may have fewer options once that service ends.
Make a list of places where the ordering link appears: your website, business profiles, menus, QR codes, social accounts and printed material. Ask whether links to individual menu items or promotions will still work after a move. A replacement homepage may be sufficient for some links, while others may need to be updated individually.
Keep the distinction clear: changing a DNS record sends the subdomain toward a different endpoint; a redirect tells a browser to request another URL. Ask each provider which method it expects and who is responsible for maintaining it.
Ask how the endpoint changes at exit
The endpoint is the destination serving the ordering experience behind the address. Before you sign, ask the prospective provider for a sample departure runbook. It should identify the records to change, the people authorized to request the change and the steps needed to make the replacement service ready.
Use the following questionnaire in a written request. The table shows who should answer each question and what a useful answer should cover. Your DNS administrator, incumbent provider and prospective provider may need to answer different parts.
| Topic | Ask | Useful answer |
|---|---|---|
| DNS control | Who can change the ordering record? | Named account owner, backup contact and change procedure. |
| Certificate | Who prepares HTTPS for the replacement endpoint? | Verification steps, responsibilities and a readiness check. |
| Exit timing | What notice and support apply when we leave? | Written deadlines, support hours and any quoted exit charges. |
| Links and redirects | What happens to old URLs after termination? | Redirect options, duration, ownership and affected links. |
| Orders and data | How do we retrieve open orders and records? | Available exports, formats, timing and access after termination. |
| Rollback | Can we return to the prior endpoint if needed? | Conditions, contact, time window and limits on the old service. |
Also ask the incoming provider what configuration it needs: the new DNS target, certificate verification details and any timing requirements. Compare that answer with the departing providerās termination date. If the old service ends before the new one is ready, a rollback may not be available.
Ask for the DNS recordās current time to live, or TTL. That setting influences how long a resolver may retain an answer before asking again. A change does not necessarily reach every visitor at once, so the transition plan should account for guests reaching either endpoint for a period. Ask both providers how open orders will be handled during that overlap rather than assuming the two systems share them.
Request written quotes for transition support and any other exit charges. Compare the operational total for the work you expect, including fixed charges, variable charges and likely exception work such as urgent support. Ask what is excluded. Have a qualified adviser review contract or tax questions where needed.
Test a sample transition plan
Hypothetical example: A restaurant owns its domain and uses order.example.com with Provider A. It wants to move that address to Provider B. The restaurantās web agency administers DNS. Assume both providers have agreed to a transition window and the agency can make the change. These are planning assumptions, not promises about any product.
First, the owner asks the agency to record the existing DNS settings and identify the person who can restore them. Provider A explains when ordering access ends and how staff can retrieve open orders and historical records. Provider B supplies its required DNS target and certificate-verification steps. The owner checks that the agency can reach both support teams during the planned window.
Next, the team walks through a simulated change on paper or in a designated practice environment. A staff member traces a sample guest journey from a website link to a menu and through a mock checkout. The simulation must not create a real payment, guest message or courier dispatch. It should also cover a failed certificate check, an old item link and an order that appears at the former endpoint. Assign an owner and response for each issue.
Set acceptance criteria before scheduling a live service pilot. For example: the replacement address displays without a certificate warning, staff can identify which system holds an incoming order, and someone is available to correct a broken link. Decide what result stops the move and who can authorize a rollback. A paper exercise checks the plan; it cannot prove that real DNS propagation, payment handling or order routing will behave as expected.
A live pilot is a separate, controlled service period with staff monitoring both endpoints and providers available for support. Agree in advance how to handle genuine orders and customer issues. Keep the old service available for the agreed window if the contract and provider permit it, but do not promise uninterrupted service or assume every order will be preserved. Review the outcome before closing the old account, and retain the records your restaurant needs.
Use the questionnaire to document your current setup and send the unanswered questions to your provider. Then ask Fleksa about restaurant online ordering, custom-domain setup, transition support and verified US availability for your location.
Frequently asked questions
Does owning the main domain mean I control the ordering subdomain?
Not necessarily in practice. Confirm who can edit the relevant DNS record and whether your provider controls any address or redirect guests use. Keep access and recovery arrangements in restaurant-controlled accounts.
Can I keep the same ordering address when I change providers?
It may be possible if you control the subdomain and the incoming provider supports the setup. Confirm DNS, certificate and transition requirements with both providers before terminating the old service.
Will changing DNS move my orders and customer records?
No. DNS changes where an address points; they do not transfer order history or resolve open orders. Ask each provider about exports, access deadlines and the handling of orders received during the transition.
