Replacing an existing site is the web development job most buyers underestimate
Building a website from nothing is comparatively simple. Replacing one that has been accumulating pages, links, forms and search visibility for a decade is a different discipline, and it is what most Nashville businesses are actually buying when they ask for a new site. The design work is the visible part. The risk sits in the web development underneath it, in everything that already exists and has to arrive on the other side intact.
Quotes that treat a rebuild as a fresh build are cheaper for a reason: the migration has been left out, or quietly assumed to be your problem. Before comparing prices, make sure every proposal answers the same question, which is what happens to the site you already have.
Inventory the old site before anyone scopes the web development
Start with a full list of addresses on the current site, pulled from a crawl rather than from memory. Almost every organisation is surprised by the total. Then bring three more lists alongside it: the pages that receive traffic, the pages that earn links from elsewhere, and the pages that people inside the company still send to customers. The overlap between those lists is smaller than anyone expects, and their union is the set of things that must not disappear.
That inventory turns a vague instruction into a scope. It tells you how many templates you really need, which sections can be retired, which forms exist that nobody remembered, and how much content has to be rewritten rather than moved. It also stops the familiar argument in month three about whether a section was ever in the brief.
Address mapping and redirects decide how much traffic survives
When the structure changes, every old address needs a decision: it maps to a new page, or it is deliberately retired. Sending everything to the homepage is the standard shortcut and it is close to the worst possible choice, because a visitor who wanted a specific page gets a general one and search engines treat the redirect as a signal that the old page is gone rather than moved.
Mapping is unglamorous web development work and it decides more of the outcome than the design does. Ask who produces the mapping, in what format, and when you will review it. Ask for permanent redirects rather than temporary ones, and ask whether each old address reaches its destination in a single hop; chains of redirects accumulate during a rebuild and quietly slow everything down. Ask what happens to addresses with tracking parameters, to the old sitemap, and to any pages that existed only in print material. Then ask to see the mapping tested on the staging site before launch, not afterwards.
Moving content is a project, not a weekend
The single most common cause of delay in a rebuild is the content. Somebody has to decide what survives, edit it to fit the new templates, find replacements for images that were never available at a decent resolution, and rewrite the pages that were written for a different business. That work is slow, it needs subject knowledge, and it cannot be done by the web development team alone.
Decide explicitly who does it and price it. If the supplier is loading content, agree the number of pages and what happens beyond that number. If you are loading it, agree how many hours that will take and who on your side has them. Agree a cut off after which no new content enters the build, because a rebuild with an open content queue never reaches a launch date. Ask also what happens to the old material that is not migrating: archived, deleted, or left running somewhere nobody maintains.
The cutover day itself
Launch is an operation, not a moment. It involves changing where the domain points, issuing certificates, moving mail records without interrupting mail, freezing edits on the old system, doing a final content sync, and confirming that forms deliver to the right inboxes once the switch is made. Each of those has a person and an order, and the order matters.
Ask for the plan in writing a fortnight before the date, with the rollback position stated: if something is badly wrong at noon, what gets us back. Ask when the old site will be decommissioned, because keeping a copy accessible for a few weeks is cheap insurance and deleting it on the day is not. Ask who is available on the day and for the two days afterwards, since most of what goes wrong is discovered by customers rather than by testing.
What to establish before you sign in Nashville
Suppliers in this market range from firms that grew out of marketing and think of a site as a campaign asset, to web development led shops that will ask about your inventory before they ask about your brand. Both can deliver a rebuild well. What you are testing is whether they have done a migration recently and can describe one specifically, including something that went wrong and what they changed as a result.
Ask how search visibility will be monitored after launch and for how long. Ask who owns the redirect list afterwards, because it needs maintaining. Ask for a reference whose rebuild went live at least a year ago and ask that reference the only question that matters, which is whether traffic recovered and how long it took. Good web development firms answer these questions without flinching, because they have the data.
If your real problem is that the site looks tired rather than that it is structurally unsound, a design led studio may be a shorter route, and if the project is an internal system rather than a public site, compare software firms instead. Verified web development companies are listed on Edvido alongside search specialists who should review the mapping before launch and social teams whose links will need updating, and buyers open to working remotely can widen the search to suppliers elsewhere in the country. When your inventory and brief are ready, send them to several firms at once and compare the migration plans line by line.