WordPress to HubSpot CMS Migration Case Study: Commercial Real Estate

Illustrative. Calderfield Commercial is a composite drawn from engagements of this shape. The figures are modelled targets — what this method is designed to produce — rather than measurements taken at a named client. They are internally consistent and should be read as a worked model, not as an audited result.

Abstract

A commercial real estate website has a problem most content migrations do not: a large share of its pages describe things that stop existing. Of the 2,400 URLs on this brokerage's WordPress site, 1,100 were property listings, and a listing that has leased is not stale content to be refreshed — it is a page whose subject is gone.

This study documents a migration to HubSpot CMS in which the interesting decisions were about URLs rather than about content. The site was inventoried, every URL was measured for the traffic and links it actually carried, and each was given one of four dispositions: moved one-to-one, consolidated, returned as gone, or left behind. Seven hundred and eighty expired listings were deliberately made to return 410 rather than redirected somewhere convenient, which is the decision most likely to be argued with and the one this study defends at length. Modelled outcomes include organic sessions at 96 percent of baseline by week 12 and 112 percent by week 24, indexed pages falling from 2,180 to 1,410 by design, and median largest contentful paint from 4.1 seconds to 1.6.

1. A Website Only Developers Could Change

Calderfield is a regional brokerage with a property management arm: 140 brokers across four offices, leasing and selling office, industrial and retail space. Its website did three jobs — advertise available space, publish quarterly market reports that win it credibility, and give each broker a page a prospect could find.

The WordPress installation was nine years old and carried a listings plugin, a forms plugin, a caching plugin, an SEO plugin and a page builder. Every one of them had been necessary at the point it was installed. Together they meant that publishing a market report required a developer, because the layout the reports used lived in a template the page builder could not edit, and updating a broker's biography required a ticket, because the bio fields were a custom post type nobody had built an interface for.

The consequence was not that the site was bad. It was that the site could only change at the rate of an external developer's availability, and so it changed rarely: market reports went out late or as PDFs attached to emails, and 60 of 420 broker pages named a broker who had left. Performance gains from a tool come from the correspondence between what it makes easy and what the work actually requires, rather than from its capability considered in the abstract (Goodhue and Thompson 1995). WordPress could do all of this. The particular installation, with its particular accretion of plugins, could not do it without a specialist.

Marketing also could not tell whether any of it worked. The forms plugin wrote to a database table and emailed a notification; nothing reached a CRM, so a broker receiving an enquiry had no record of the visitor's prior activity, and no report could connect a market report's readership to a subsequent lease.

2. The URL Inventory, and Where the Value Actually Is

The first deliverable was a census, produced by crawling the site, exporting analytics for the preceding twelve months, and pulling referring domains per URL.

The site held 2,400 indexable URLs: 1,100 property listings, 640 blog posts and market reports, 420 broker biographies, and 240 category, tag and system pages. The distribution of value across them was the finding, and it was not subtle. Seventy-eight percent of organic sessions arrived at 144 URLs — 6 percent of the site. Ninety-one percent of referring domains pointed at 38 URLs, nearly all of them market reports.

That concentration is what makes a migration of this kind tractable. The instinct in a content migration is to treat all URLs as equally precious and to move everything, which converts an editorial decision into a mechanical one and carries the site's accumulated debris across intact. Knowing that 38 pages hold the link equity means those 38 can be treated with individual care while the rest are handled by rule.

It also reframes what is at risk. Use is an outcome of a system's quality rather than a property to be assumed, and a page nobody has visited in a year is not an asset being protected by being migrated — it is a cost being carried forward (Delone and McLean 2003). Six hundred and forty of the 2,400 URLs had received no organic session at all in twelve months.

3. Four Dispositions for a URL

Every URL was assigned one of four outcomes, by rule where possible and by hand for the 38 that carried the links.

Move one-to-one applied to 1,260 URLs whose content had a direct destination and whose path could be preserved: market reports, active listings, current broker pages. Preserving the path is worth real effort, because a redirect that resolves is still a redirect, and a chain of them is a slow one.

Consolidate applied to 360 URLs where several thin pages had a single better destination — a submarket described across four near-duplicate pages became one, with the other three redirecting to it. This is the disposition that requires judgement, because consolidation is indistinguishable from dilution when done carelessly.

Return as gone applied to 780 expired property listings, discussed in the next section.

Leave behind applied to the remainder: tag archives, paginated category pages, attachment pages and the WordPress-specific detritus that had been indexable without ever being intended for a reader.

A redirect is a claim that two representations refer to the same thing, and that claim is either true or it is not. The representation and the thing it stands for are distinct, and a mapping that ignores the distinction produces exactly the failure described below — a URL asserting that a leased warehouse and a list of available warehouses are the same subject (Wand and Wang 1996).

4. The Expired Listing Problem

This is the decision the sector forces, and the one where the convenient answer is wrong.

When a property leases, its page describes something a visitor cannot have. There are four available responses and three of them are common. Keep the page live as-is, which advertises unavailable space and disappoints every visitor who arrives. Redirect it to the listings index, which is what most brokerage sites do. Redirect it to the relevant submarket or property-type page, which is a softer version of the same move. Or return 410 Gone, which states that the page existed and does not any more.

The engagement chose 410 for 780 of them, and the reasoning is worth setting out because it runs against the instinct to preserve.

A redirect from an expired listing to an index page is not a redirect to equivalent content; it is a redirect to a different subject. A visitor searching for a specific address arrives at a list that does not contain it. Search engines have long treated such redirects as soft 404s rather than honouring them, so the supposed equity preservation is largely illusory, and the practice leaves a site accumulating thousands of redirects that all point at the same handful of pages — which is a signal about the site rather than about any individual URL. This is platform and search behaviour as observed in August 2026 rather than a documented guarantee, and a reader planning the same decision should verify it against current guidance rather than against this study.

The exception was made deliberately and by hand. A listing that had itself attracted links or meaningful traffic — 34 of the 1,100 — was kept as a permanent record of the transaction, marked clearly as leased, with the deal terms that were public and a link to comparable available space. Those pages are useful to the market and to the brokers, and their subject still exists in the sense that a completed transaction is a fact.

Underneath this is a mismatch between what a general-purpose CMS assumes and what the business is. Packaged systems embed assumptions about the domain, and where those assumptions do not fit, the organisation adapts itself, adapts the package, or builds at the boundary (Sia and Soh 2007). Both WordPress and HubSpot assume content is authored and then persists. A listing is authored, persists briefly, and then becomes false. Nothing in either platform models that lifecycle, so the firm had to encode it as a policy and a scheduled job rather than expect it as a feature.

5. What the Plugins Were Doing

Five plugins had to be accounted for, and the accounting is more interesting than the replacement.

The listings plugin held property data in a custom post type with 40 fields, which mapped cleanly onto a HubSpot custom object and a set of templates. The forms plugin was replaced by HubSpot forms, which is where most of the measurable gain sits: enquiries now create or update a contact, associate to the property, and appear against the broker's record with the visitor's prior page history attached. Historical submissions — 4,100 of them — were imported as contacts with a source property naming the original form, on the reasoning that a lead who enquired eighteen months ago is worth having and a submission with no contact record attached is worth nothing.

The caching plugin had no equivalent and needed none, its function being subsumed by the platform's own delivery. The SEO plugin's contribution was reduced to data: its per-page titles and descriptions were exported and re-applied, and the rest of it — the analysis screens, the readability scoring — was not replaced, because nothing downstream consumed it.

The page builder was the difficult one, and it produced the migration's largest manual effort. Its layouts existed as serialised markup inside post content, which is portable only in the sense that the characters can be moved. Two hundred and forty pages had to be rebuilt against HubSpot modules by hand.

The capability that results is not the software but the combination of the software with people who can now use it, and that combination is what actually produces a process outcome (Karimi, Somers, and Bhattacherjee 2007). The point of the rebuild was that marketing could publish a market report without a developer, and that outcome depended on the module set being built for the way this firm writes reports rather than on HubSpot CMS in general.

6. Cutover and the First Crawl

The cutover was mechanically ordinary and worth recording only for the sequence, which people get wrong in a specific way.

DNS time-to-live was lowered to five minutes forty-eight hours ahead. The redirect map — 1,620 rules covering the move and consolidate dispositions — was loaded and tested against the live WordPress site before anything changed, by requesting each source URL and confirming the destination existed and returned 200. Testing a redirect map after cutover finds the same errors several hours later and in front of visitors.

At switchover the new sitemap was submitted, the old one left in place for a fortnight so that the crawler would find the retired URLs and receive their status codes rather than simply losing sight of them, and server logs were watched for 404s that the map had missed. The first fortnight produced about 1,900 unmapped 404 requests, nearly all of them from URL patterns nobody had inventoried — print variants, feed URLs, and a set of query-string filters the listings plugin had generated. Those were mapped or dispositioned as they appeared, and by week four the rate had settled at about 40 a week, which is the background noise of scrapers and stale links.

An incomplete inventory is a data quality failure like any other, and it shares their characteristic economics: the cost is not paid by whoever produced the gap but by everyone downstream of it, which in this case means visitors arriving at nothing during the fortnight it took to find them (Redman 1998). A crawl of the site is not the same as a list of the URLs the world believes the site has, and the server logs are the only place the difference appears.

7. Measuring Whether It Worked, and Over What Window

A content migration cannot be declared successful in the week after it happens, and the pressure to do so is considerable.

The measurement plan was fixed before cutover: organic sessions and organic entrances to the 144 URLs identified as carrying the traffic, indexed page count, and Core Web Vitals, compared against the same twelve-month baseline at weeks 4, 12 and 24. Week 4 was expected to be down and was, at 81 percent of baseline. Reading that as failure would have been the standard error, and having written the expectation down in advance is what made it survivable.

Site performance is not a cosmetic property in this context: download delay is among the factors most consistently associated with whether a site succeeds with its visitors, alongside navigation and content (Palmer 2002). Median largest contentful paint fell from 4.1 seconds to 1.6, and while attributing traffic recovery to that specifically would overreach, it is the change most likely to have contributed alongside the URL work.

Indexed pages fell from 2,180 to 1,410. That is a reduction of 35 percent and it is the intended outcome rather than a loss, since the removed pages are the tag archives, the paginated lists and the 780 expired listings. A site reporting fewer indexed pages after a migration is usually reported as a problem, and here it is the deliverable.

8. Modelled Outcomes

Figures below are modelled targets for this method rather than measurements at a named client, as stated at the head of this study.

Organic sessions against baseline. 81 percent at week 4, 96 percent at week 12, 112 percent at week 24.

Indexed pages. From 2,180 to 1,410, by design.

URLs in the estate. From 2,400 to 1,410, comprising 1,260 moved, 360 consolidated into 96 destinations, 780 returned as gone, and the remainder left behind.

Median largest contentful paint. From 4.1 seconds to 1.6.

Unmapped 404 requests. From about 1,900 in the first fortnight to about 40 a week by week 4.

Form submissions reaching the CRM. From none — the plugin wrote to a database table and sent an email — to all of them, associated to the property and the broker.

Time to publish a market report. From about three days, gated on developer availability, to same-day and self-serve.

Broker pages naming someone who had left. From 60 of 420 to zero, and now maintained by the office managers who know when someone leaves.

9. Limits

The figures are modelled rather than measured, as stated.

The traffic recovery figures are the most fragile thing here. A twenty-four week window spans market movements, seasonality and whatever else search engines did in that period, and no counterfactual exists. A migration executed identically in a different quarter could produce a materially different curve for reasons entirely outside the work.

The 410 decision is defensible and it is not costless. It permanently discards whatever residual value those 780 URLs held, and a brokerage whose listings routinely attract links — a firm marketing trophy assets, for instance — would find the hand-curated exception applying to far more than 34 pages. The decision should scale with how much individual listings are linked to, and that is a property of the market segment rather than of the platform.

This study also does not address the property management arm's tenant portal, which stayed where it was. Migrations are frequently scoped to exclude the hardest system and then reported as though the whole estate moved, and that exclusion is stated here rather than left to be inferred.

Four months is a short window in which to judge an implementation. Difficulties surfacing in that period tend to be attributed to the new system when they are as often the ordinary shape of people relearning their work, and separating the two requires longer than this study observes (Gattiker and Goodhue 2005).

Platform behaviours described — how HubSpot CMS handles redirects and status codes, and how search engines treat a redirect to a non-equivalent page — were as observed in August 2026. Both change, and the vendor's current documentation rather than this study should be treated as authoritative.

10. What Recovered Slowest

The market reports came back first, within about six weeks, which was expected since they hold the links and their URLs were preserved exactly.

The broker pages took until week 20, and the reason is instructive. Their URLs had moved: the WordPress structure put them at /team/first-last/ and the rebuild used /brokers/first-last/, a change made for clarity that nobody costed. Each redirect resolved correctly and every page was better than its predecessor, and they still took five months to return to their prior positions. A path change is not free even when it is executed perfectly, and the correct time to ask whether a tidier URL is worth five months of recovery is before the decision, not after.

The listings recovered fastest of all and matter least, because a searcher looking for available industrial space near a particular interchange is not seeking a URL — they are seeking a current list, and the current list is a page that did not move.

Site quality as visitors experience it is a composite of several dimensions rather than a single property, and the ones that recovered at different rates here map onto that: informational content behaved differently from navigational structure, and both differently from the transactional listing pages (Loiacono, Watson, and Goodhue 2007). Treating a site as one thing that recovers at one rate is what produces the panic at week four.

11. Conclusion

The migration moved a website, and almost none of the difficulty was in moving it. It was in deciding what a URL is for, and in accepting that a page describing a warehouse leased two years ago is not content the site should keep, redirect, or apologise for. It should say the thing is gone.

What made the decisions possible was the census: knowing that 6 percent of the URLs carried 78 percent of the traffic and that 38 of them held nearly all the links turned an argument about preservation into an allocation of care. The 38 were handled by hand and the rest by rule, and the site that came out is 41 percent smaller and, by the twenty-fourth week, busier than the one that went in.

References

Delone, William H., and Ephraim R. McLean. 2003. "The DeLone and McLean Model of Information Systems Success: A Ten-Year Update." Journal of Management Information Systems 19 (4): 9–30. https://doi.org/10.1080/07421222.2003.11045748

Gattiker, Thomas F., and Dale L. Goodhue. 2005. "What Happens After ERP Implementation: Understanding the Impact of Interdependence and Differentiation on Plant-Level Outcomes." MIS Quarterly 29 (3): 559–585. https://doi.org/10.2307/25148695

Goodhue, Dale L., and Ronald L. Thompson. 1995. "Task-Technology Fit and Individual Performance." MIS Quarterly 19 (2): 213–236. https://doi.org/10.2307/249689

Karimi, Jahangir, Toni M. Somers, and Anol Bhattacherjee. 2007. "The Role of Information Systems Resources in ERP Capability Building and Business Process Outcomes." Journal of Management Information Systems 24 (2): 221–260. https://doi.org/10.2753/MIS0742-1222240209

Loiacono, Eleanor T., Richard T. Watson, and Dale L. Goodhue. 2007. "WebQual: An Instrument for Consumer Evaluation of Web Sites." International Journal of Electronic Commerce 11 (3): 51–87. https://doi.org/10.2753/JEC1086-4415110302

Palmer, Jonathan W. 2002. "Web Site Usability, Design, and Performance Metrics." Information Systems Research 13 (2): 151–167. https://doi.org/10.1287/isre.13.2.151.88

Redman, Thomas C. 1998. "The Impact of Poor Data Quality on the Typical Enterprise." Communications of the ACM 41 (2): 79–82. https://doi.org/10.1145/269012.269025

Sia, Siew Kien, and Christina Soh. 2007. "An Assessment of Package–Organisation Misalignment: Institutional and Ontological Structures." European Journal of Information Systems 16 (5): 568–583. https://doi.org/10.1057/palgrave.ejis.3000700

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

Conflict of Interest Statement

RevOps HQ is a certified HubSpot Solutions Partner and derives revenue from HubSpot implementation work, including CMS migrations of the kind this study describes. The study recommends a migration onto the platform this firm is paid to implement. Section 9 states what the recommendation excludes and where the central decision would not transfer, and readers should weigh the commercial interest against the fact that a competently maintained WordPress installation would have solved the publishing constraint described in section 1 without any migration at all.

Acknowledgments

The office managers who now maintain the broker pages accepted work that used to belong to a developer, and the figure that fell from 60 to zero is theirs rather than the platform's.