How Long Does a Website Revamp Actually Take?

Plan a website revamp timeline of eight to twelve weeks for a typical Malaysian SME site: roughly fifteen to thirty pages, staying on WordPress, no new payment or booking integrations. Only two or three of those weeks are the build itself. The rest is decisions, content, design and review rounds, and that is where the overruns come from.

That is a planning range rather than a measurement, and it rests on one assumption that is rarely true: that somebody in the business answers within a couple of days every time they are asked. Change that single assumption and the same project runs to five months with nobody doing anything wrong. Below is where the weeks actually go, and which of them belong to you rather than to whoever builds the site.

What a website revamp timeline actually contains

Six stages, in this order. They overlap at the edges, but the dependencies between them are real: nothing can be designed around content nobody has decided, and nothing can be built on a design nobody has approved.

• Audit and decisions — 1 to 2 weeks. What stays, what goes, what the site has to do that it cannot do now. Cheap to do properly and expensive to skip, because most mid-project scope changes trace back to a decision postponed here. Whether a revamp is the right answer at all is what our guide to choosing between a revamp and a full rebuild is written to settle.
• Content — 2 to 6 weeks, and mostly yours. Service pages rewritten, photographs taken, policies and coverage areas confirmed. This is the widest stage in the project and the one businesses consistently budget at zero days.
• Structure and design — 2 to 3 weeks. Sitemap, page templates, the homepage, the mobile layouts. Quick when the content exists, guesswork when it does not, which is why placeholder text in a design review is a warning rather than a detail.
• Build — 2 to 3 weeks. Templates implemented, content loaded, forms wired to a mailbox somebody reads, speed tuned on a real phone. This is the part people picture when they ask how long a revamp takes, and it is almost never the longest.
• Review and testing — 1 to 2 weeks. Real devices, real forms, the enquiry path walked end to end. Also the stage that stretches by precisely as many rounds as there are people who have not looked yet.
• Launch and the fortnight after — 1 to 2 weeks. Redirects, analytics, Search Console, and the small breakages that only appear once real traffic arrives.

Laid end to end those stages come to more than twelve weeks. They do not run end to end: content gets written while templates are designed, and testing starts before the last page is finished. Eight to twelve weeks is what that overlap buys. When content arrives only after the design is done, the stages queue up instead, and the same six stages become five months.

A revamp runs at the speed of its slowest answer, not its fastest worker.

Why the same project takes eight weeks for one business and five months for another

Page count is the variable everyone asks about first and rarely the one that decides the date. Six other things move it much harder.

• Whether the content already exists. Not “we have a brochure somewhere” — finished words for every page, photographs that are genuinely yours, and prices or ranges somebody is willing to publish.
• How many people have to approve. One decision-maker with the authority to say yes is worth more to a schedule than any amount of project management. Three is workable. Five means each round of feedback costs a fortnight and usually contradicts itself.
• Scope added after sign-off. A booking form, a second language, a product catalogue “while we are at it”. Each is reasonable alone, and each restarts design and build for the pages it touches.
• Third parties running on their own calendar. A bank onboarding an FPX merchant account, a booking system’s API access, an SSM document somebody has to dig out, a domain sitting with a registrar whose login left with a former employee. None of these are your web team’s to hurry.
• Grant paperwork, where it applies. The MSME Digital Grant MADANI administered by BSN requires the business to appoint a panel service provider before applying, and to pay the balance to that provider within fourteen days of approval. That sequence sits in front of the project rather than inside it.
• The calendar itself. Hari Raya, Chinese New Year, Deepavali and the school holidays each remove a week or two of approvals from any Malaysian project. A revamp booked to launch in the same fortnight as a long holiday launches after it.

The approval point deserves an argument rather than an assertion. Nielsen Norman Group compared 83 of its own usability consulting projects and found almost no relationship between how many people took part in a round of testing and how many findings that round produced; the trend line across the studies is close to flat. That work is about usability testing rather than sign-off meetings, so treat the parallel as a parallel: the fifth reviewer of a homepage is unlikely to raise what the first three missed, but the week spent waiting for them is real. Settling this early is the argument for working through a website revamp checklist at the quotation stage rather than the review stage.

The stage that starts on launch day

Launch is not the end of the schedule. If the revamp changes any URLs — and a restructured site usually does — search engines have to find the new addresses and move the old signals across, on Google’s clock rather than yours.

Google Search Central is unusually plain about it: for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones, and longer for larger sites. The same documentation asks you to keep the redirects in place for as long as possible, generally at least a year, so that links pointing at old addresses keep their value.

Two practical consequences. A dip in the second week after launch is not automatic evidence that the revamp failed; it is what a re-crawl in progress looks like, and the judgement call comes weeks later. And whoever builds the site needs to still be reachable a month afterwards, because the redirect that was missed and the form that stopped sending will both surface under real traffic rather than in testing.

How to take a month off the schedule

Every one of these is a decision made before kickoff, and together they are worth more than any promise of a faster build.

• Write the content first. Rough final copy for the ten pages that matter beats polished copy for all forty delivered in week seven. Photographs take longer to arrange than anyone expects, so book them in week one.
• Name one approver. One person who can say yes, with a named deputy for when they travel. Collect other opinions before the review, not during it.
• Freeze the scope in writing at design sign-off. Anything raised afterwards goes on a list for after launch. The list is not a refusal; it is the reason the date survives.
• Start the third parties in week one. Payment gateway, booking system, domain and hosting access, any grant application. These wait on other organisations and cost nothing to begin early.
• Agree what “finished” means before you start. Every service page live, forms tested on a real phone, redirects in place, analytics recording. A written definition ends the drift that turns the last week into three.
• Settle the maintenance arrangement at the same time. A site nobody looks after is the site that needs revamping again in four years, and this is the cheapest moment to decide it.

None of that shortens the build, because the build was never the problem. It shortens the gaps between stages, and on most projects the gaps are larger than the work.

Frequently asked questions

Where iRevamps fits

The schedules that go wrong are almost never the ones with an ambitious build; they are the ones that started before anyone decided what the site had to do. Our website revamp and design service begins with the audit and decisions stage described above, and its output is a written scope listing the content you owe us with dates attached, before a design exists. If you need a launch date you can put in front of a board, that is the stage that produces one.