A website chatbot migration succeeds when the replacement preserves the visitor tasks you still need, and makes every unsupported task visible before you switch. Moving an export file or changing an embed code does not establish that continuity. Start with a record of current answers, source pages, actions and contact paths. Decide what the replacement can preserve, what needs rebuilding and what must stay with another system.
For a small website, this can be a practical worksheet rather than a large migration project. The important distinction is between replacing public information answers and replacing an entire support operation. A tool that answers from published pages may fit the first job while leaving account lookup, appointments, agent routing or conversation history unresolved.
Author: Achla AI, Organization. Reviewed 14 October 2026. This guide combines current primary documentation with an original behavior-preservation worksheet, prepared with AI assistance. The examples are hypothetical; no customer migration, uptime result or product benchmark was measured. The purpose is to help a site owner make a bounded replacement decision.
What are you actually replacing?
Begin with the visitor experience you currently provide. “We have a chatbot” is too broad to be a useful requirement. On one site it means answering opening hours. On another it includes identifying customers, reading orders, changing appointments and connecting conversations to employees.
Write down a task in the visitor’s words: “What documents should I bring?” Then record where the answer comes from and what happens next. A public preparation page may support an information answer. “Which documents have I already uploaded?” requires personal context and a different access boundary, even though both questions contain “documents.”
Keep source accuracy separate from the migration decision. If the public page is outdated, preserving the old answer is not the right goal. Correct the authoritative source through its normal owner, then evaluate the replacement against that approved information. Our website-content chatbot guide explains the source and retrieval background; this article concerns continuity when changing providers.
List the current interface too. A floating button, an embedded box and an existing search input are different visitor paths. Record the pages where each is available and the ordinary contact or search route that remains usable when the chatbot cannot help.
Build a behavior-preservation ledger
Use one row per important visitor task, not one row per vendor feature. The following worksheet is an original planning framework, not a claim about any provider’s migration tools.
| Field | What to record | Why it changes the decision |
|---|---|---|
| Visitor task | A representative, non-sensitive question or action | Defines the behavior worth preserving |
| Approved source | Current public URL and the fact it supports | Separates useful evidence from an old response |
| Current behavior | Answer, citation, action or contact destination | Reveals what the visitor would lose |
| Dependency | Public content, identity, external system or staff | Prevents an answer widget replacing an unverified workflow |
| Export evidence | Available format, scope and authorized owner | Establishes what can leave the old system |
| Destination evidence | Documented input and supported behavior | Establishes what the new system can actually use |
| Decision | Preserve, rebuild, not portable or stop | Makes unresolved work explicit |
| Route and owner | Page, responsible person and acceptance condition | Turns the decision into a reviewable change |
The four decisions have different meanings. Preserve means the new workflow has evidence for the required behavior. Rebuild means a documented replacement path exists but still needs preparation. Not portable means an old feature or record cannot simply move across; decide whether another system should retain it. Stop means the replacement cannot meet a required task and should not take over that route.
Add a short acceptance condition to every important row. For a policy answer, it might be “the response includes the required condition and links to the current public policy.” For a contact path, it might be “the visitor can reach the existing contact page without submitting private information to the answer widget.” These are proposed conditions for your review, not outcomes already achieved.
Keep the owner column specific. The website maintainer may own placement, an editor may own a policy and a support manager may own the contact destination. One person can hold several roles, but the record should still distinguish the decisions.
Do not mark a row “preserve” just because both vendors describe a chatbot. Record the exact scope: a supported public answer, its source expectations and its visitor path. Migration acceptance is a decision you make from evidence, not a badge provided by the worksheet.
Why an export is not proof of an import
An export answers a question about the old provider: which records can an authorized person obtain, in which format? An import answers a different question about the destination: which data can it accept, and what meaning or behavior will it retain?
For example, Intercom’s conversation export documentation describes several methods for conversation content and data, with different scopes and permissions. It does not establish that another provider can restore those conversations as active sessions, recreate their routing or treat them as a knowledge source.
Keep conversation transcripts, public knowledge pages and configuration records in separate categories. A transcript may contain names, account details or information supplied privately. It is not automatically suitable material for a public website-answer assistant. Do not copy private conversations into public knowledge to make a replacement appear knowledgeable. Use authorized, deidentified question formulations and approved public source expectations for the migration worksheet.
Ask the destination for its documented ingestion contract. If there is no evidence for a competitor-specific import, leave that field unknown. A managed public-site crawler may let you rebuild answers from existing public pages; that is a different process from importing another vendor’s knowledge configuration or chat history.
Achla’s installation documentation describes its website widget and verification workflow. It does not establish a native competitor-import or conversation-history migration feature. Evaluate the public-answer task on its own merits rather than assuming an export file will bridge the gap.
Record answers, sources and paths separately
Consider this hypothetical service website. The rows illustrate decisions to investigate; they are not observed test results.
| Current task | Evidence needed for the replacement | Proposed decision |
|---|---|---|
| Explain the published cancellation policy | Current policy page, supported answer and usable source link | Preserve only after verification |
| Look up a customer’s individual appointment | Authorized account integration and appropriate access behavior | Stop the public-content replacement path |
| Request help from an employee | A documented staffed route and clear visitor expectations | Retain or rebuild separately |
| Open ordinary site-search results | A working search destination from the relevant page | Preserve that path independently |
| Review a previous private conversation | Documented history portability and authorized handling | Not portable until evidence proves otherwise |
A changed citation URL is not automatically a failed migration, and an unchanged URL is not proof of a correct answer. Check whether the cited page supports the required information and remains accessible to the intended visitor. Do not promise retained citations merely because the underlying public pages stayed online.
Human support also has its own contract. Zendesk’s handoff documentation describes configured handoff and responder behavior for its product. That functionality does not carry over to a separate answer widget by default. An ordinary contact link can preserve a contact destination, but it does not recreate a native transfer of conversation ownership.
Prepare replacement readiness before changing the live route
Keep a recoverable record of the current installation: the owning template or connector, relevant placement settings, page scope, vendor account owner and the known way to restore the previous visitor route. Store necessary configuration securely; do not put private keys or session data in a shared worksheet.
Installation ownership matters because a provider change affects the website as well as the answer service. Intercom’s web installation guide documents its own embed integration. Use each destination’s current instructions rather than adapting one vendor’s script attributes or lifecycle calls to another.
Check browser requirements before selecting a replacement. A third-party script contributes work to the page, as web.dev’s guidance on third-party JavaScript explains. That is a reason to inspect the actual page and its dependencies, not to promise a performance improvement from changing vendors. Browser security policy can also block required resources; MDN’s CSP guide explains that boundary. Keep an organization’s policy intact and assess compatibility with the new widget.
Define acceptance in terms of the ledger. Which public questions and source expectations must remain supported? Which ordinary paths must remain available? Which dependencies are explicitly excluded? Notre Dame’s chatbot guidance addresses testing, launch and maintenance; use that operational perspective without turning this migration into another generic answer benchmark.
Plan one controlled change and a return path
Choose a limited visitor route for the proposed change and identify who can authorize it. Specify the current state, intended replacement state and conditions that would trigger a return to the previous configuration. Record the actual recovery procedure before changing anything live.
Use one active chatbot loader on the evaluated page. Two overlapping widgets make it harder to tell which system answered, which control owns the interaction or which request failed. Achla’s current installation instructions likewise require a single inclusion and warn against combining its connector with a manual tag. Separate candidate comparisons from simultaneous production installation.
A return plan is more than “we can reinstall the old tool.” Confirm that the authorized owner still has access, the relevant configuration is recoverable and the old service can support the required route. These are questions to verify, not guarantees of rollback or zero downtime. Preserve previous artifacts and account information needed for recovery; any later retirement or deletion requires its own decision.
After a separately approved change, review the same ledger rows on the intended pages. Record supported behavior, missing behavior and unresolved ownership. An apparent improvement on one answer does not compensate for losing a required human or account-specific path.
When should you proceed, revise or keep the current provider?
Proceed to a bounded replacement evaluation when the required public tasks have an evidence-backed destination and the independent visitor paths remain accounted for. Revise when a concrete source, placement or ownership gap has a named fix. Keep the current route when an essential behavior remains unsupported or its recovery path is unknown.
Choosing a managed service rather than a custom stack is a separate decision covered in managed AI search versus DIY. A migration worksheet should preserve the responsibilities you need, even if the replacement has fewer features or a different interface.
Where does Achla fit in a replacement decision?
For a public website-answer task, review Achla’s documentation-search offering, its current pricing and troubleshooting guidance against your completed ledger. If that documented scope fits, begin the existing onboarding flow. Keep private-data, human-support and transactional requirements with separately verified workflows. The useful outcome is a defensible replacement decision, with every important visitor task still owned.
