- Inventory the existing site
- Map content and addresses
- Rebuild and verify
- Launch and monitor
Establish why the website is moving
Write down the problems the move is expected to solve. A site may be difficult to edit, inconsistent on mobile or unclear about services. Those are different problems, and each needs its own acceptance test. If the existing platform can support the required improvement, compare that option before committing to the work of migration.
Webflow's migration overview states that moving from another platform involves rebuilding layouts, styles, CMS structure and interactions. It is not an automatic conversion. That distinction matters when comparing proposals. A low page count can still involve significant effort if those pages contain unusual forms, many downloads or relationships between different kinds of content.
Inventory the information an Orem customer may need
Start with current pages, images, files and important external links. Include items that may not appear in the main navigation, such as instructions linked from confirmation emails or a PDF used by returning customers. Ask staff which pages they send to people during a sale or service conversation. These uses may reveal valuable content that a visual homepage review would miss.
Orem's official business-information page provides local business resources, while the city's online-services directory groups practical tasks. Those public sources illustrate the value of making information findable, but they do not establish what a private company's website must contain or which platform it should use. Confirm business-specific addresses, visiting instructions and service arrangements directly with the owner.
A hypothetical Orem repair business might need to preserve equipment preparation instructions that staff send before an appointment. A hypothetical retailer near University Place might need current store directions and a product-care resource. A hypothetical training business might have enrollment details linked from existing emails. These are planning illustrations, not Dappr projects or claims of affiliation with the shopping center.
Decide the destination of each important address
Keep a record of the old URL and its intended new destination. Retain useful addresses where practical, and plan appropriate redirects for necessary changes. Avoid sending every retired URL to the homepage when a more relevant destination exists. Google documents URL mapping and redirect handling as central parts of a move with address changes.
Review internal links as well as redirects. A visitor should not repeatedly pass through old addresses to reach the rebuilt site. Check links in navigation, article text, downloadable documents and existing campaign material under the business's control. If a page contains information that is still needed, moving platforms is not a reason to discard it without an explicit content decision.
Search visibility can fluctuate during a migration, and no responsible scope should guarantee an unchanged ranking. Establish a baseline from available analytics and Search Console before launch. Record important pages and inquiries so later troubleshooting can distinguish a tracking problem from a broken page or a change in customer behavior.
Test content mapping before importing everything
Webflow supports importing CMS content from a CSV file, but an import still needs a suitable Collection and correct field mapping. Prepare a small representative sample first. Include a long title, formatted text, images, a downloadable file and any relationship your content model requires. Check the resulting page rather than assuming a successful import message proves the content is correct.
Review formatting, special characters, image descriptions, dates and links. Confirm which information belongs in structured fields and which belongs in the page body. Keep a source copy until the migration is verified. When content requires manual cleanup, name that work in the scope instead of expecting the owner to discover it after the build is approved.
Rebuild the behaviors people depend on
List the existing site's functional tasks separately from its page inventory. Contact forms, appointment links, search, maps and embedded media all need a decision. Some may be recreated; others may remain external services. Identify the owner and subscription for each dependency so a launch does not break because an old account was closed too early.
For inquiries, test where the submission arrives, what the visitor sees and who responds. If the project includes Dappr's own CRM, document the agreed connection and data fields. Do not assume implementation of unrelated CRM systems. Use representative test details, avoid real sensitive customer data and include a clear fallback contact method if a form or connected service fails.
Use the rebuild to improve clarity and accessibility
A migration gives the team a chance to replace confusing navigation and inconsistent headings with a more understandable structure. Keep service descriptions concrete and distinguish an inquiry from a confirmed booking. Make contact details easy to find without suggesting an office or service coverage the business does not have.
Apply W3C design guidance to contrast, labels, navigation and feedback. Then test the actual pages with a keyboard and at narrow widths, including long content and form errors. Review image cropping and text readability on the real templates. These practical checks should be documented; they are not a substitute for a broader accessibility assessment when one is required by the project.
Separate preview approval from launch readiness
A preview can demonstrate the new design before the production domain changes. Use it to verify content, representative page types and the editing workflow. Before launch, check domain access, the intended indexing settings, important redirects and the final form destinations. Agree on who authorizes the change and who is available to resolve problems.
After launch, revisit the important customer tasks on the public domain. Monitor errors and available search reports, and confirm that measurement still records the intended actions. Retain the migration map and a record of known limitations. A launch plan should include a response procedure if a critical inquiry or ordering route stops working, rather than treating publication as the end of responsibility.
Prepare an informed project scope
Bring your current website address, a list of essential pages and files, access ownership information and the reasons for considering Webflow. Dappr serves Orem remotely from its staffed St. George office. The proposal should distinguish design, content preparation, migration, integrations, testing and ongoing maintenance. Current platform subscriptions and account requirements need confirmation separately.
Start the project conversation with a list of useful pages, downloads and contact routes that must survive the migration. Use that example to compare the proposed deliverables, review responsibilities and acceptance evidence. Dappr can coordinate the project remotely from its staffed St. George office. Ask the proposal to identify what is included, what depends on another provider and what needs investigation before a commitment. Keep account ownership, maintenance and the staff handover explicit so the result remains usable after the initial build. A project-specific estimate should follow those requirements rather than assumptions about a city or platform.
Questions before you begin
Can an existing website be automatically converted to Webflow?
Webflow's current migration overview describes a rebuild of layouts, styles and content structure rather than an automatic conversion. Some structured content can be imported, but design and functionality still need planned implementation and checking.
Which URLs should we preserve during the move?
Review useful current addresses, including pages linked from other sites, customer emails and business materials. Preserve them where practical. For necessary changes, map each important old address to an appropriate destination and test the result.
Will changing platforms guarantee better search rankings?
No. Platform choice alone does not guarantee rankings, and migrations can cause fluctuations. Plan the move carefully, retain useful content and monitor available search and measurement data after launch.
What makes a sample import useful?
Choose records that expose realistic complexity: long text, images, files, dates and relationships. Inspect the public-facing result and links. A simple sample that omits the difficult content may give false confidence.
When should we close the old website account?
Only after the responsible parties confirm that required content, functionality, access and migration checks are complete, and that the old account is no longer needed for agreed recovery or reference work. Include that decision in the launch plan rather than guessing.
Sources and further reading
- https://help.webflow.com/hc/en-us/articles/51622865825171-Migrate-your-site-to-Webflow-overview
- https://help.webflow.com/hc/en-us/articles/33961290794771-How-do-I-import-content-into-the-Webflow-CMS
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- https://orem.gov/business-info/
- https://orem.gov/onlineservices/
- https://www.w3.org/WAI/tips/designing/