If a new restaurant website fails at launch, you need more than a copy of the old pages. Prepare a person who can authorize a rollback, access to the accounts that control the site, a way to restore the previous version, and a plan for checking orders and email afterward.
A rollback returns guests to an earlier working setup. It may mean restoring files on the same host or pointing the domain back to a previous host. The right method depends on what changed during launch. Either way, the old site must still be usable, and someone must know how to bring it back.
Set rollback triggers and name the decision owner
Choose one person who can make the call during launch. For an independent restaurant, that may be the owner or general manager. Give that person a technical contact who can explain the options and carry out the change. If an agency controls the website, agree in advance on who is available and how quickly they can respond.
Define a few failures serious enough to trigger a decision. A broken menu photo might be fixed on the new site. A guest being unable to reach the ordering page during dinner service is a different problem. Other triggers could include the wrong ordering destination, a reservation link that fails, or the domain displaying an error on multiple devices.
Decide what evidence the owner needs before acting. The manager can report what staff and guests are seeing. The website contact can identify whether the problem is limited to one page or affects the whole site, and estimate the time to fix it. The ordering provider can help determine whether an order was received. Use these inputs to decide whether to repair the new site, temporarily direct guests to a working ordering page, or roll back.
Hypothetical example: A restaurant launches a new site at 4 p.m. Staff find that the order button leads to an error on two phones. The manager tells the owner, and the website contact cannot identify a quick fix. The owner has already agreed that an ordering failure still unresolved after 15 minutes calls for a rollback decision. The owner authorizes it while staff use the existing phone-order process. The 15-minute threshold is an operating choice, not a promise that restoration will finish in that time.
Record the decision and the time. If the new site can still receive orders through another route, assign someone to monitor it until the team knows where incoming orders are going. A rollback changes the website visitors see; it does not necessarily transfer or cancel orders already placed.
Preserve the old site, domain and DNS details
Before launch, make a short access list and store it securely. Include the domain registrar, DNS provider, old and new hosting accounts, website editor, ordering provider and business email administrator. Record the account owner, the person who can sign in, recovery methods and an urgent contact. Do not put passwords in a shared launch document; use your normal secure credential process instead.
The domain is the address guests type. DNS records help direct services using that domain. Hosting is where the site runs. These may be controlled by different companies or by different people at the same company. The guide to restaurant domain ownership can help you identify who holds the keys.
Save a dated record of the DNS settings before changing them, including the website-related records and email-related records. Ask the person managing DNS to identify exactly which records a rollback would change. Changing a website address should not become an excuse to replace unrelated email settings. Also note where the site’s security certificate is managed and ask the host how secure access will work if the previous site is restored.
Keep a usable backup of the old website and confirm whether restoration also requires a database, uploaded menu files or configuration settings. A page export alone may not restore forms, ordering connections or other functions. If the old site remains on its original host, confirm that the account, subscription and domain configuration will remain active for the agreed recovery window.
There is a trade-off: keeping old hosting active may add cost, but canceling it immediately can make a return harder. Get both providers to explain the steps, access and timing for the actual setup. Ask what content or settings could be lost if the team restores an older copy. For example, menu edits made only on the new site may need to be entered again after a rollback.
Practice restoration without affecting guests
Write the restoration sequence in plain language: who approves it, who signs in, which backup or host to use, which website-related settings change, and who verifies the result. Include a contact and an alternative for each critical role. The checklist below makes the handoff visible to the owner as well as the technical team.
| Checkpoint | What to prepare | Who confirms it |
|---|---|---|
| Decision | Failure triggers, review time and authority to roll back | Owner or manager |
| Access | Registrar, DNS, hosting and backup access with recovery contacts | Account owners and website contact |
| Restoration | Previous site copy or active host, plus the exact change sequence | Website contact |
| Service checks | Ordering destinations, reservations, menu and email checks | Manager with relevant providers |
The table separates authorization from execution and checks. One person may cover several roles, but every row needs a named owner in your own plan.
Practice first in a staging environment or another isolated copy if your provider offers one. Have the technical contact restore the previous version there, then have a manager follow the checklist on a phone and a computer. Confirm that pages load and that buttons point to the intended destinations. Use test data or a provider-approved test mode for any deeper checks. A simulation must not charge a real card, send a guest message or dispatch a courier.
Ask the technical contact to record the steps that needed clarification and update the checklist. This exercise can show whether the team has access and understands the sequence. It cannot prove that a live domain change will reach every guest immediately, that every connected service will behave the same way, or that no order will be missed.
If you choose a live service pilot, plan it separately for a quiet period with the relevant providers and staff available. Agree on how real orders will be monitored and handled. Do not treat a practice environment as proof that live traffic has switched. Domain changes can take time to appear consistently, so check from more than one device or connection and keep the team informed while the change takes effect.
Verify ordering, reservations and email after rollback
Once the previous site appears, check what a guest can actually do. Open the home page and menu on a phone. Confirm the restaurant name, hours, location and phone number are current enough to use. Follow the order button to its destination and check that it is the intended store and menu. If the old site uses an external ordering link, make sure it has not been replaced, expired or pointed at the wrong location.
Check reservation links and any other important paths, such as gift cards or catering inquiries. For forms and transactions, use safe test methods agreed with the provider; do not submit a real guest inquiry or payment just to see what happens. If a function cannot be verified safely, record the gap and arrange a supervised live check separately.
Ask the email administrator to confirm that the email-related DNS settings remain correct and that business mail is working. A website appearing normally does not establish that email works. If there is a problem, involve the person who manages mail before changing records further.
During the transition, assign one person to watch each place an order might arrive: the previous ordering destination, the new destination and any staff-managed fallback such as the phone. Reconcile orders already received against the restaurant’s order workflow. Tell staff which link to give guests and what to say if someone reports trouble. Update any temporary guest notice when the correct destination is confirmed.
Do not retire the new setup immediately after rollback. Preserve relevant order information and notes about the failure, then agree on how the team will repair and relaunch it. Before the next attempt, compare the tools and control you need with this restaurant website builder comparison, including who can restore the site and maintain its connections.
Next step: Use the checklist with your current website and ordering contacts. If you are considering a new restaurant website or online ordering setup, ask Fleksa about availability in your US location and how your domain, ordering links and rollback responsibilities would be handled.
Frequently asked questions
Does a website backup include the ordering system?
Not necessarily. A website backup may restore pages but not an external ordering service, its menu or its settings. Ask each provider what is backed up and how the restored site will connect to ordering.
How long does a rollback take?
It depends on the restoration method, account access and how quickly domain changes become visible. Ask your website and DNS contacts for an estimate for your setup, then prepare staff for an overlap period rather than assuming an immediate switch.
Should I cancel the old website host after launch?
Set an agreed recovery window first. Confirm that the new site and its connections are working, preserve the records and backups you need, and understand the cost and consequences before ending the old hosting service.
