Choosing Clone Versus Template for a 120-Site Country Rollout
A retail brand will launch 120 country sites in 90 days. A pilot site for Canada has 14 GB of files, 2,300 nodes, and a working store locator; it must be replicated for 15 English-speaking countries. The other 105 sites need only the base install profile and a shared product feed. All sites use the same code stack. Country teams need to map domains and configure SSO with local identity providers. One country's legal team requires its site live in 3 days and cannot wait for the full rollout.
1. Which creation method should be used for each cohort, and why?
Read the worked answer
Reasoning: The two cohorts have different content needs, so one method should not be forced on both.
- The 15 English-speaking countries need the pilot's content structure, store-locator configuration, and 2,300 nodes. Clone the Canada pilot for these sites; a clone copies the database and files and preserves the working configuration.
- The 105 remaining sites need a clean base plus a product feed. Create them from the install profile/site template, then configure the feed. Cloning the pilot would carry Canada-specific content, menus, and settings that would need cleanup.
- The 3-day country should not wait for the full rollout. If it needs only base functionality, create it from the template immediately. If it needs the store locator content, clone the pilot first, then remap domain and SSO.
2. Sequence the clone and post-clone work for the 15 English-speaking countries, including domain and SSO cutover.
Read the worked answer
Reasoning: A clone copies the source site's database and files, including its domain and identity-provider settings, so post-clone remediation is mandatory.
- Freeze structural changes on the Canada pilot during the clone window and record the source state.
- Clone one site first as a canary; verify content, files, store locator, cron, and search index.
- For each clone, immediately replace the domain, SSO issuer/client settings, site name, and analytics IDs; clear caches and reindex search.
- Test login through the local identity provider before DNS cutover; keep a staging domain until SSO passes.
- Repeat in batches through the API, then run a post-clone checklist across all 15 sites.
3. What risks would you flag to the steering committee?
Read the worked answer
Reasoning: The schedule is tight because clone and SSO work are sequential and failure-prone, not because site creation itself is slow.
- Clone drift: if the pilot changes after cloning starts, the 15 sites will differ. Freeze the pilot or document the exact source version.
- SSO mismatch: local identity providers may use different protocols or attribute mappings; each site needs its own validation.
- Domain/DNS delays can block launch even when the site is ready.
- File storage growth from 15 copies of a 14 GB site affects capacity planning.
- SEO and content duplication if the pilot's content is cloned without localization.
- The 3-day site is the highest schedule risk; give it a separate owner and rollback plan.