Landing page migration is a separate decision from your storefront build. Merchants replatforming to SuiteCommerce or Shopify usually take one of three paths: start clean with a small set of standard pages, rebuild the existing pages inside the new platform, or keep them on their current CMS and connect the two experiences. Needless to say, it is always better to pick the chosen path during the scoping process, rather than tackling it during the development phase.
Key points
If you are moving from an older SuiteCommerce Advanced build to a newer version, or from SuiteCommerce Advanced to standard SuiteCommerce, your informational content is already inside NetSuite. The theme can change, the front end can change, but the page records and their URLs generally don’t. That’s a very different conversation from a platform change, and it’s one of the reasons an SCA upgrade carries less content risk than people expect. A Site Builder and legacy migration may deserve another conversation.
The question gets more serious when the content lives somewhere else. A merchant running NetSuite as the system of record, a storefront on one platform, and a marketing site on WordPress has two content estates and one of them is about to move, or stay, or be rebuilt. Somebody has to decide which.
It is usual that any site that has been running for a few years collects pages nobody necessarily planned for: knowledge base articles, product information pages, spec sheets and manuals, brand pages, press releases, seasonal campaign pages, and a blog with years of posts sorted into categories. Some merchants have a limited amount of those pages. Some have hundreds.
Two numbers generally decide the path. The first is how many pages actually exist, by type. The second is how much of your organic traffic they earn. Pull the Pages and screens report in GA4 and find the pages that account for roughly 80% of organic sessions. In most B2B catalogs that list is far shorter than the full page count, and it’s the list worth protecting. Pages that rank well and that existing customers still use are valuable assets. Pages nobody has visited in two years are not worth paying much attention to.
Most SuiteCommerce themes ship with a small set of informational pages: About Us, FAQ, Contact Us, Privacy Policy. For merchants whose content estate is thin, dated, or barely visited, the practical answer would be to write fresh copy for those pages and go live.
This is the fastest and more cost-effective path, and it suits merchants whose organic traffic sits on product and category pages rather than content pages. It stops making sense the moment a content audit shows real organic value sitting on pages you would be deleting.
The second path suits merchants who want one platform instead of two. If NetSuite is already the ERP and their storefront is moving to SuiteCommerce, keeping a separate WordPress install alive means a second hosting bill, a second set of updates, a second security surface, and a second place your team has to remember to publish in.
Within this path, informational pages can be rebuilt as SuiteCommerce content pages through Site Management Tools, NetSuite’s content management layer for SuiteCommerce. Because SuiteCommerce runs natively on NetSuite, there is no middleware sitting between the storefront and the ERP, which is usually the reason merchants want the consolidation in the first place.
Two things are worth being blunt about. First, the SEO migration has to be planned as part of the same workstream, not after it. Redirect mapping, URL structure, titles and meta descriptions, and sitemap updates all need to be handled so the pages keep their indexation.
Second, this is a real project. Rebuilding a library of a hundred plus product information, brand, media, and press release pages is a body of delivery work that sits next to the storefront build rather than inside it, and it deserves its own estimate and its own timeline. We have run it exactly that way: a parallel workstream alongside a SuiteCommerce implementation, with page construction and SEO migration tracked together.
The third path is the one merchants rarely hear offered, and oftentimes it is the right one for them. If you have an in-house marketing and content team that publishes weekly and knows WordPress well, moving them into a new CMS costs you twice: once for the rebuild, and again in retraining and losing publishing speed. In that situation the better answer can be to leave the content where it is and make the two systems feel like one site.
The mechanics are straightforward. SuiteCommerce handles the shop flow: category pages, product listing, product detail, cart, checkout, and the customer account area. The existing CMS keeps the information pages. Header, footer, navigation, typography, and the design system are matched across both, so a visitor clicking from a product page into a buying guide sees the ‘same site’. The URLs sit on different systems. The experience the user gets does not reveal it.
The trade-off is honest: you keep two platforms, two sets of updates, and two publishing workflows. For a team that is fast and comfortable in the CMS they already have, that cost is usually lower than a full rebuild.
| Path 1: Standard pages | Path 2: Rebuild in SuiteCommerce | Path 3: Keep the CMS | |
|---|---|---|---|
| Best when | Few information pages, little organic value on them | Consolidating onto NetSuite, content has real SEO value | Strong in-house content team already fluent in the current CMS |
| Typical page count | Under 10 | 20 to 200+ | Any, usually 50+ |
| Relative cost | Lowest | Highest, scoped as a parallel workstream | Moderate, mostly design alignment |
| Platforms to maintain after go live | One | One | Two |
| SEO work required | Redirects for retired URLs | Full redirect map and metadata migration | Minimal, existing URLs stay put |
| Who publishes content afterwards | Marketing, in Site Management Tools | Marketing, in Site Management Tools | Marketing, in the existing CMS |
Whichever path you take, the pages that move need a redirect plan built before going live, not after. Keep the URL identical where the platform allows it. Where it cannot stay, map old URLs to the new ones and use permanent redirects. Carry the title tags, meta descriptions, and H1s across rather than rewriting them during the move, then submit updated sitemaps and watch coverage and impressions for the first few weeks. Google’s guidance on site moves with URL changes is the reference to hand your SEO agency.
The useful moment to settle all of this is during the scoping phase, when the page inventory, the traffic data, and the team’s publishing habits are all still on the table. In practice that means agreeing on four things before development starts: how many pages and of what type, which path you are taking, who writes and who builds, and who owns the SEO migration.
Across multiple eCommerce projects, we lay out these scenarios during scoping so merchants can choose with the numbers in front of them. Sometimes the answer is a full rebuild in SuiteCommerce. Sometimes it is four standard pages and nothing else. Sometimes the smartest move is to leave a WordPress install exactly where it is. What matters is that the choice is made deliberately and priced honestly at the start.
No. Content that lives outside NetSuite does not travel with a storefront build by default. Migrating, rebuilding, or retaining those pages is its own decision and its own scope, agreed during planning.
Yes, and for teams with an established content operation it’s sometimes better economics. SuiteCommerce runs the shop flow, the blogging platform keeps the information pages, and matching the header, footer, and design system across both makes it read as a single site to the customer.
Not if the migration is achieved respecting best practices, including a redirect map, preserved metadata, and updated sitemaps. Ranking loss in replatforms usually comes from URLs changing with no redirect plan, not from the platform change itself.
Generally no. In an upgrade or a move between SuiteCommerce versions the content stays inside NetSuite, so the page records and URLs are preserved. That’s what makes upgrades a lower content risk than cross-platform replatforms.
Enough that it should be scoped and estimated separately from the storefront. A library of that size is a delivery project running in parallel with the implementation, covering page construction, content transfer, and the SEO migration attached to it.
Yes. The same three paths apply when the destination is Shopify or Shopify Plus. Shopify has native pages and a blog, so the rebuild path looks different mechanically, but the decision (rebuild, retain, or start clean) and the SEO work behind it are the same.
Santiago brings 15+ years of extensive experience in digital marketing and eCommerce. His background involves working in SuiteCommerce agencies, growth agencies, and affiliate marketing. Santiago possesses a diverse skill set and a deep understanding of the industry. His proficiency in psychology allows him to establish strong connections with clients.
Your product catalog isn’t the only thing that needs a plan when you replatform to SuiteCommerce. Here’s how an automated content migration process protects your rankings and your budget.
Keying an integration on NetSuite’s internal ID works fine until you move from sandbox to production and every ID shifts. Here’s the stable identifier pattern that avoids the problem entirely.
Manual quote re-keying is costing your team hours and your customers patience. Here’s how a native CPQ approach inside SuiteCommerce fixes it, tying configuration and pricing directly to NetSuite.
