Start with what people can already find
The inventory should show which pages exist, what they do and how people reach them. Gather the current website addresses and identify their associated content, images and documents. A migration becomes easier to assess when there is a concrete list of everything that needs to keep working in the new system.
When I dealt with moving my WordPress website to an application, I first asked for an analysis of the existing site and a list of its pages. Preserving the addresses was part of the request. That forces you to look at what is already published before deciding how to organise the new project.
The homepage rarely represents the whole job. There are older articles that remain useful, service pages, contact details, downloadable documents and legal pages that only appear in the footer. If the inventory depends entirely on the main menu, some of those assets can disappear without anyone having made that decision.
A sitemap helps discover addresses, but I would not treat it as proof that the list is complete. I would add a content export and, where available, records of visits and incoming links. I would also keep a reference copy of the old site to resolve differences during the review.
This inventory connects with the diagnosis before proposing a marketing plan: first understand what exists and the purpose it serves. A page with few visits may contain information that someone needs just before contacting the business. Volume alone does not determine its future.
To prepare your next step, explore Developing applications with AI.
Give every address an explicit destination
Every old URL should have a recorded decision: retain the same page, direct visitors to equivalent content, or remove it for a defined reason. Avoid leaving this choice implicit in the AI's work. The mapping between source and destination is a decision document that then guides implementation and testing work.
Consider a hypothetical example: a company has a page about classroom training and decides to reorganise its navigation. If the offer remains the same, changing the menu does not require changing the address. It can update the presentation and retain the path that customers and partners already know.
If two pages are genuinely replaced by one more complete page, the mapping should point to that replacement. A permanent redirect can serve this change. Sending every old address indiscriminately to the homepage leaves visitors without the content they wanted and hides decisions that should have been reviewed individually.
Some content also stops making sense. Removing it requires an editorial decision, rather than an attempt to invent an equivalent destination. In the table, I would record the reason and who validated it. The person testing can then distinguish an intentional removal from a page forgotten during the transfer.
Include addresses that already circulate outside the website. Imagine a QR code printed on a leaflet or a link sent in a commercial proposal. The team can correct the menu in seconds, but it cannot retrieve every item already distributed. Preserving that access has practical value even when it never appears in a design discussion.
Give AI requirements that can be checked
The implementation request should combine the inventory, URL decisions and observable criteria for each kind of page. Explain what should appear, who can edit it and what happens in forms. Ask the AI to identify uncertainties before turning assumptions into behaviour in the new application that the team will use.
I would separate content, presentation and operation. Content includes titles, text, images and language; presentation defines how they are displayed; operation covers editing, incoming requests and permissions. Looking similar to the original does not demonstrate that all three parts have been transferred correctly to the new system.
A useful requirement would be: “This article must open at the specified address, display the complete text and retain useful internal links.” Another would be: “This form needs to validate its fields and show a confirmation consistent with what was actually recorded.” These are conditions someone can observe without guessing intentions.
Before building, apply the same care I propose when planning an application with Claude Code. The AI needs to know the project boundaries, the data required and what depends on your decision. Asking for a visual copy of a website leaves too many operational questions unanswered.
I would also define how the team will update content after migration. If changing a description starts requiring a code change, there may be an unplanned maintenance cost. A bespoke application only addresses the process when the responsible person can operate it under the business's actual working conditions.
Test the journeys before switching websites
The review should start from the old addresses and follow the new website as someone seeking information or wanting to act. Check complete pages, images, downloads and forms. Combine automated tests of the URL list with a review of important journeys, because a technically valid response can display the wrong content.
For example, a page can open without an error and have lost half its article. An image may exist but belong to a different service. A button can lead to the correct page in the wrong language. These cases require comparison against the requirements and source material, beyond a list of positive responses.
For forms, use an environment and test data that do not send real messages to customers. Check required fields, understandable errors and the outcome of a valid submission. If there is a private area, also test what someone without access cannot see or change in the application.
Check page titles, canonical addresses, links between languages and the new system's sitemap. Also confirm that protections used during development will not prevent public pages from being discovered after the switch. A test environment's configuration should not slip unnoticed into the final website that visitors and search engines receive.
Sharing this review helps uncover different failures. Someone who knows the content can identify an omission; someone handling enquiries can spot missing information. AI can prepare checks and locate differences, but accepting a content change still requires a defined editorial criterion that people can apply consistently.
Switch with a way to recover and monitor
Going live should have a responsible person, a recoverable copy of the previous state and checks prepared for the period immediately afterwards. Define what would justify a quick correction or a rollback. Then monitor errors and real journeys without treating an initial fluctuation in visits as automatic proof of success or failure.
Before the switch, decide how to handle content or requests that might arrive in the meantime. In a hypothetical example, exporting a site in the morning and migrating it at night can leave changes behind. The team needs to know when editing stops, how the last update transfers and where new requests go.
The option to roll back also needs to account for data. Restoring the old version of the website should not erase submissions received by the new application. The plan must therefore identify where those records are stored and how they will be reconciled after a reversal. A visual copy does not resolve this dependency.
After the change, monitor missing pages, incorrect destinations and problems reported by users. Compare important journeys with the initial list and record what was corrected. Prior testing reduces surprises, but it does not make launch day the final opportunity to review whether the work meets its requirements.
This is a concrete application of using AI in business beyond the chatbot: helping analyse, build and verify a change against your criteria. The migration is complete when useful content and tasks work in the new system. Appearance alone cannot establish that the work is ready to accept.