Help Articles – Page 12

Help topic · Page 12 of 34

In practice, none. "Migration" tends to describe the content and URL move. "Replatform" tends to describe the broader project, including the new CMS, integrations, and team workflow. The checklist applies to both.

Read full article →

No, and you shouldn't. A migration is the cleanest moment you'll ever get to retire content that isn't earning. Categorise everything into keep, merge, rewrite, and retire before the build starts. Pages that get fewer than ten organic visits a month and carry no backlinks are usually retirement candidates.

Read full article →

A minimum of 12 months. Google has stated it processes 301s relatively quickly, but external sites and email signatures take longer to update. Twelve months covers the long tail. For high-value URLs with sustained backlink growth, keep them permanently.

Read full article →

Separately, in that order. Migrate the CMS first with the existing design intact, prove the platform works, then redesign on the new stack. Combining the two doubles the variables when something breaks. If the business case forces them together, freeze URL structure and content so the redirect map stays valid.

Read full article →

An incomplete redirect map. Specifically, URLs that earned backlinks years ago, aren't in the current sitemap, but still drive referral traffic and link equity. A crawl of the live site catches the obvious ones. A backlink export from Ahrefs, Semrush, or Search Console catches the rest.

Read full article →

It can, and most migrations do see a short-term dip. A clean migration recovers in four to eight weeks. A migration without a complete redirect map, or one that changes URL structure without 301s, can lose rankings permanently. The difference is phase one planning, not platform choice.

Read full article →

For a mid-market marketing site, plan on three to six months end to end. Enterprise builds with multiple regions, languages, or commerce integrations usually run six to twelve months. The build itself is rarely the long pole - the content audit, redirect mapping, and stakeholder approvals are.

Read full article →

Yes. Core dna has direct integrations with common ERPs (SAP, NetSuite, Microsoft Dynamics 365), PIMs, CRMs, payment processors, scheduling and booking systems, and identity providers, plus an open API and the Hooks orchestration engine for everything else. ERP sync is real-time and bidirectional. For multi-brand operators, the ERP integration is configured once and runs across every brand.

The same applies to operational systems. We pull schedules from your booking system so customers see real-time availability per location, push leads into your CRM, and sync customer records into your member portal.

Read full article →

Yes, and you decide what they see. The customer graph is unified at the platform level. Each brand sees order history, loyalty, and account information scoped to that brand by default. Your privacy and brand-equity rules decide whether the customer experiences themselves as a single account across the portfolio or as separate accounts per brand. Your internal team sees the full portfolio-level view for service, marketing, and analytics.

Read full article →

SKUs can live in one brand, multiple brands, or every brand. Master product records carry the shared attributes (specifications, dimensions, raw imagery). Brand-specific layers carry the brand-scoped attributes (merchandising copy, brand imagery, brand pricing). Inventory can be unified (one stock pool serving all brands) or partitioned (each brand has its own stock), configurable per product class. Cross-brand cart and checkout are configurable; some operators allow it, some do not.

Read full article →

Each brand is configured as a tenant on a shared platform. Each tenant has its own domain, storefront, brand identity, content, and merchandising. The catalog primitives, customer graph, pricing engine, and back-office integrations are shared across tenants. You decide per data class what is shared and what is brand-scoped: SKUs, customers, inventory, loyalty, reporting. Add a brand by configuring a new tenant in admin, not by buying another platform.

Read full article →

Yes. Pricing engines, tax rules, currency, payment methods, and shipping rules are scoped per brand and per market. The same SKU can have different prices and tax treatments per brand. Promotions, discount stacks, and loyalty rules are also brand-scoped. Where multiple brands legitimately share a rule (volume discount across the portfolio, parent-company tax exemption), the rule is configured once and applied across the relevant brands.

Read full article →

Core dna is managed infrastructure. We handle hosting, security patches, performance, core upgrades, and ongoing managed services for configuration changes. Your team owns content, day-to-day editing, design tweaks within the system, and operational workflows.

Read full article →

A new location inherits the master site, gets its own URL or sub-section, its own admin permissions, and its own catalog or service scope. The setup is a configuration, not a separate build. Most networks add a new location in days, not weeks.

Read full article →

Yes. Roles and permissions are scoped per location and per content type. A branch manager can have full edit on local promotions, view-only on the corporate catalog, and no access to brand templates. Approval gates can require corporate sign-off before specific changes go live.

Read full article →

Page 12 of 34
Page 12 of 34