Web Hosting in Fort Wayne, IN

The short list of what genuinely has to change

Ask what has to be fixed on an old site and the honest answer is a short list. On a manufacturing, insurance or healthcare site most of it is a morning of work rather than a project.

What is actually broken on most old sites

• A certificate. A site served without one gets a warning in front of it in every browser, and a purchasing office vetting a new supplier, or a patient checking a practice for the first time, reads that warning as a verdict on the company. SSL covers what is involved, and it is no longer an expensive item.
• The phone layout. A page laid out for a desktop screen in 2005 is not unusable on a phone, it is merely unpleasant, and the patient checking your hours and the buyer checking a spec are both holding one. That is a stylesheet problem, not a rewrite.
• Image weight. Photographs of a shop floor or a waiting room taken on a current phone and dropped straight onto an old page are far larger than anything that page was built to carry, and they are usually the entire reason it feels slow.
• Anything with a login or an upload attached. Old contact scripts, old comment systems and old plugins stopped being maintained years ago, and they are the commonest way a site of this age gets broken into. Where the form is collecting a policy detail or a patient's name, that stops being merely embarrassing. Website security goes through it properly.
• The ability to correct a sentence yourself, today. Coverage wording changes, a clinician leaves, a certification is renewed, and the page has to be right that afternoon rather than after a ticket.

That is close to the complete list. Note what is not on it. Plain pages written in ordinary code in 2004 still work exactly as they did, because the code they were written in did not stop being valid. Specification tables, capability lists, coverage explanations and decades of product detail do not need touching. A page looking plain is not the same as a page being broken, and to somebody sourcing a process or checking whether you take their insurance, the plain page frequently outperforms the one with moving parts.

The awkward item is the design itself. If it reads as a site from another era, that is a real cost with a first time visitor and almost none with the buyer who already knows what you make. It is the most expensive thing on the list and the only one that can be done gradually. New styling over the same pages, at the same addresses, carrying the same words, gets most of the benefit of a rebuild and risks none of the loss.

The last thing worth checking is what the site is sitting on. An account untouched since the site was built is often running a version of the underlying software the host stopped supporting years back. That shows on the day something breaks, when nobody is left who knows how to fix it. Before any of it is decided, take a dated copy of the whole thing. Twenty years of capability lists and coverage wording cannot be retyped from memory, and website backups matter most on a site nobody has a copy of.

Moving an old site without leaving pieces behind

Moving a site that has sat in one place since the early 2000s is no harder than any other move, but the failure modes differ. The rule is that the site gets copied, not recreated. Every file comes across as it is, under the same name, in the same folder. The moment somebody tidies the structure up on the way over, the move has turned into a rebuild.

Addresses matter more here than anywhere else, because an old site has had longer to be linked to. Pages ending in .html, files in a folder named after a product line, a specification sent in an email years ago. Each should either keep working at exactly the address it has now or send the visitor to the right replacement. Website migration covers the order that has to happen in.

Old sites also lean on server features that were ordinary once and are not always switched on now. A form handler, a hit counter, a small script that builds a page from a text file. Test each on the new account before the domain is pointed anywhere, rather than finding the contact form silent a week later.

Mail is the part that genuinely hurts when it goes wrong, and on a long lived domain it is more tangled than anyone remembers. There will be addresses nobody uses, forwarding for people who left, and a catch all quietly collecting things somebody still reads. Write down what exists before anything is touched. Email migration covers keeping mail flowing while the rest of it moves.