Replacing a chatbot without breaking the dialogue

A chat assistant is rarely replaced because it stopped working. It is replaced because it no longer matches what the company sells and promises today: the range has grown, the answers have not. Among companies already using AI, customer contact is the most common field of application at 86 percent (Bitkom Research). At the same time 64 percent (Bitkom Research) of companies see themselves as latecomers on the topic, and 72 percent (Bitkom Research) say they lack the required know-how in-house. A migration that consists of swapping one script therefore ends in a week where nobody knows where the old conversations are and which address still answers. This article treats the switch for what it is: a move with an inventory list, a calendar, dual running and a shutdown date.

Enlarge graphic

Labels in the illustration

• Dual running: both systems available, only one of them visible
• Component
• keep
• rebuild
• retire
• Knowledge base
• Test the export
• Close gaps before the move
• –
• –
• Chat transcripts
• –
• –
• Keep the metrics
• Delete raw text after the term
• Widget embed
• –
• Replace one script
• Remove the old cookie too
• –
• Redirects
• –
• Old help addresses
• Hold 1 year, at most 3
• –
• Approval roles
• Names, not shared logins
• Recheck rights on the move
• –
• –
• Dual running ends only once the redirects are live and the old script has gone from every page

Migration matrix: what moves, what gets rebuilt, what goes

Why the switch is not a script swap

From a distance a chatbot looks like one line of source code: a script, a key, a window in the bottom right. That view is the most common reason a migration goes wrong. In reality a chain grown over years hangs off that line. The knowledge base holds wordings somebody signed off on. The transcripts hold personal data with retention periods of their own. On top sit redirects from old help pages and a list of people holding rights in the old system. Swap only the script and you leave that chain behind. It shows up weeks later, when a customer asks about a commitment the new system cannot find.

The second reason is the starting position. Across the EU only 19.95 percent (Eurostat) of companies with at least ten employees use AI at all, and text generation – the technology behind every chat window – reaches 8.76 percent (Eurostat). At the same time chat sits close to revenue; 34.70 percent (Eurostat) of AI-using companies apply the technology in marketing and sales. Running the change as a project buys freedom: the new assistant does not have to reproduce the old one, it has to deliver what is needed today. Which building blocks come into question is set out on the page about custom functions.

Inventory: what is really inside the old system

The inventory is the one piece of work that should be finished before notice is given. After that a clock starts and access to the old system narrows. In practice: build a list in which every component gets a row, and answer three questions per row. Does the component exist in a format that can be exported? Who inside the company last approved it? What happens if it goes missing – would a visitor notice, a colleague, or nobody? Out of the answers comes the migration matrix with three columns: keep, rebuild, retire.

For the embed it pays to look at the page itself rather than at the vendor's manual. Third-party scripts appear on 90 percent (Web Almanac) of pages or more, and the embedding chain has a median of 3 (Web Almanac) – one embedded service usually pulls in further services. Check in the browser's network log which addresses are still requested after removal and which cookie is left behind. Around 60 percent (Web Almanac) of all cookies come from third parties; the predecessor's cookie belongs on the same deletion list as its script. What a clean embed looks like is shown in the article on embedding the assistant in a website and shop.

• Knowledge base: everything the assistant answers from, with revision date and approval.
• Transcripts: raw text, metrics and ratings kept apart. The metric is worth keeping, the raw text rarely is.
• Embed: script, display rules, consent layer, colours, languages and every page where the window appears.
• Connections: inventory, calendar, ticketing, shipping – every link with credentials and purpose.
• Addresses: help pages, handover forms and transcript links that had their own address in the old system.
• Approval roles: who may change answers, who publishes them, who can view transcripts.
• Contracts: term, notice period, retrieval window after the agreed transition period, and who deletes the data.

This list is not a formality. 72 percent (Bitkom Research) of companies say they lack the required know-how in-house – without a written handover list the switch depends on the very vendor you are leaving. The connections to your other systems carry the most silent dependencies; an overview is available under integration.

The switch runs on a calendar, not on a preferred date

Switching providers of data processing services now sits inside a European framework with stated deadlines. The notice period for initiating the switch may not exceed two months (Official Journal of the European Union). A transitional period of at most 30 calendar days (Official Journal of the European Union) follows. If the move is technically unfeasible in that window, the provider notifies this within 14 working days (Official Journal of the European Union) and names an alternative period, which may not exceed seven months (Official Journal of the European Union). A minimum period of 30 calendar days (Official Journal of the European Union) remains for retrieving the data, and it only starts once the agreed transition period has ended. And from 12 January 2027 (Official Journal of the European Union) providers may no longer impose switching charges for carrying out the switch. These figures give the project a frame: the move is an appointment, not an open-ended process.

• Week 0 – inventory: fill in the matrix, test the exports, document approval roles and connections.
• Week 1 – notice and retrieval plan: serve notice, get the retrieval window confirmed in writing, ask for a named contact.
• Weeks 2 to 4 – build: import, trim and approve the new knowledge base; connect each system individually; test the embed on a preview address.
• Week 5 – dual running: both systems live, only one of them visible. The new window moves onto more pages step by step.
• Week 6 – cutover: remove the old script, put the redirects in place, drop the old cookie.
• Weeks 7 to 10 – retrieval and deletion: collect the remaining data, obtain confirmation of deletion, revoke access.

The schedule has a catch worth spotting early: the minimum retrieval period starts once the transition period agreed between you and the provider has ended, not on the day your team has time. The customer may extend that transition period once – if you need it, agree it in writing before the clock starts. So place the retrieval at the beginning. Where the data sits afterwards belongs in the plan as well – the framework for that is described under privacy and hosting.

Dual running: two windows, one customer dialogue

A clean migration needs a phase in which both systems are technically available while only one is visible. In practice dual running means showing the new window on a few pages first, then in one section, then everywhere. That matters most in busy periods; how spikes in chat can be absorbed is described in the article on peak season support spikes. The boundary counts: two visible chat windows on one page are not dual running, they are a defect. The visitor then picks which one to address, and a share of the conversations lands in a system that will be shut down in four weeks.

Dual running also carries a price that lands on the page itself. The median page already loads 83 (Web Almanac) third-party requests and 708 KB (Web Almanac) of JavaScript, of which 280 KB (Web Almanac) uncompressed goes unexecuted; the median blocking time on mobile sits at 1,916 milliseconds (Web Almanac). It gets uncomfortable on inner pages: on responsiveness, home pages and inner pages sit 11 percentage points (Web Almanac) apart – and the widget usually loads everywhere. So keep dual running tight: a fixed end date, a page list per visible window, and a daily look at where the old script still loads. What happens when a system does not answer during the transition is covered in the article on fallback levels and failover.

Addresses, redirects and visibility afterwards

Many chat systems create addresses of their own: a help page, a handover form, occasionally one page per transcript. 79.01 percent (Eurostat) of companies in the EU have a website, so a switch usually touches an existing, indexed site. The guidance for site moves is clear: keep redirects in place for as long as possible, at least 1 year (Google Search Central). Chains of several hops should be kept low, ideally at most 3 (Google Search Central). Moving into the index takes time: for a small to medium site most pages move within a few weeks (Google Search Central), longer for larger inventories. For a migration that means the redirects are live on cutover day, not afterwards.

The move is also an opportunity to reset the counting. Carry the old system's metrics forward unchanged and you compare two different definitions: a conversation, a session and a resolved enquiry rarely mean the same thing in two systems. So record in writing, before the cutover, what will be counted from now on and when the series starts. Which evaluations are worth having is set out under conversation analytics.

Accessibility, data protection and the load in the browser

A new chat window is measured against the same criteria as any other control. Text requires a minimum contrast of 4.5:1 (W3C); on the web that is rarely met – only 31 percent (Web Almanac) of mobile pages stay within the minimum values. For chat a second point applies: answers appear in the transcript after the fact, and anyone using a screen reader only learns about them if the area is marked up accordingly. Just 33 percent (Web Almanac) of pages use any markup for dynamically loaded content. The transitional provision of the German Accessibility Strengthening Act allows services to be provided until 27 June 2030 (Federal Ministry of Justice) using products lawfully in use before 28 June 2025 – a newly installed window does not fall under it. The micro-enterprise exemption applies only below 10 people (Federal Ministry of Justice) plus turnover thresholds. What is checked in detail is covered in the article on an accessible assistant.

On the data protection side two deadlines keep running regardless of the project. Access and erasure requests must be answered without undue delay and in any event within one month (Official Journal of the European Union) – including while the data sits between two systems. If something goes wrong during the transfer, the controller notifies the supervisory authority where feasible within 72 hours (Official Journal of the European Union). One rule follows: while the move is under way a named person knows which body of data sits in which system. That role belongs in the project plan.

The migration in eight steps

The sequence below has proven itself when taking over existing assistants. It is deliberately cut so that every step has a visible result: a document, a preview address, a confirmation.

Before the cutover comes a test run with real questions from the old system. Take the thirty most frequent enquiries of recent months, put them to the new assistant and compare the answers with what your subject-matter team would say. How to structure such a test run is described in the article on acceptance testing before go-live.

• Fill in the migration matrix: five components, three columns, one owner per row
• Test the exports from the old system before notice is served
• Note the contractual deadlines: notice period, transitional period, retrieval window, deletion commitment
• Import, trim and approve the new knowledge base – with a date and a name per entry
• Connect and test each system individually, not all together on cutover day
• Run dual operation with an end date and keep the page list per window in writing
• On cutover day: remove the old script, drop the old cookie, put the redirects in place
• After the move: retrieve the remaining data, obtain deletion confirmation, revoke access, redefine the metrics

Once the export from the old system is available, the migration matrix can be filled in row by row. What moves into the new knowledge base and what is better rewritten becomes clear from your own content; the pricing page shows which plan carries the volume you take over.

Frequent questions