Bohemia Interactive: An Analysis-Led Move from Drupal to WordPress
How Business Analysis Canada led Bohemia Interactive's move from Drupal to WordPress through user journeys, a content model, redirects and acceptance criteria.
- ~3 months of analysis before the build
- 5 audience journeys defined first
- 6 content types in the new content model
- 7 roles in the permissions matrix
Project at a glance
- Client
Bohemia Interactive, an independent game studio founded in 1999 and known for Arma and DayZ - Website
The studio's public site, covering its games, news, careers, press and studio information, in English and Czech, with links out to the community forums, wiki and store - Engagement
A move from Drupal to WordPress, led as analysis rather than as a platform swap. Journeys, content, URLs and roles were specified first, and WordPress was fitted to that baseline. - Duration
About 3 months of analysis and content modelling, followed by about 4 months of build, migration and cutover - Our role
Lead business analysis: journey elicitation, content inventory, acceptance criteria, content model, URL and redirect map, language and search requirements, roles and editorial workflow, migration mapping and cutover checks, working alongside designers, WordPress developers and QA - Scope
Game pages, news, careers, studio pages, press materials and engine pages. The forums, wiki and store stayed on their current platforms and were linked from the new site, not migrated.
The challenge
What problem was the client trying to solve?
What problem was the studio trying to solve?
The site had grown for years around the games, and the Drupal build had grown with it. Moving platforms was the moment to decide what the site was for, rather than copy everything across.
- Costly upgrade
Keeping the Drupal build current would have needed a major upgrade, close to a rebuild in effort. - Unused structure
Content types, fields and categories had built up over time, and many were no longer used. - Inconsistent game pages
Game pages were structured differently from one title to the next, so players found different information in different places. - Outdated content
Old campaign pages, retired event pages and duplicate news items sat alongside current content and appeared in search results. - Weak site search
Site search often returned old news ahead of the game or guide a player was looking for. - Languages out of step
English and Czech versions had drifted apart, with some pages translated and others not. - Inbound links at risk
Years of inbound links from press, wikis, forums and video descriptions pointed at existing URLs, so a careless move would break them. - Broad permissions
Publishing a news post and changing a game page used the same broad permissions, so a routine update could damage an important page.
Our business analysis approach
How did we approach the engagement?
How did we approach the analysis?
- Purpose and audiences
We ran workshops with marketing, community management, press relations, talent acquisition and the web team to agree what the site is for and who it serves. - Journey elicitation
Players come for a game, a patch note or a modding path. Press come for a fact. Candidates come for a role. We wrote these journeys down from interviews, analytics on top landing pages and search queries, referral sources, and feedback gathered by community managers, before anyone mapped a template. - Content inventory
We crawled the Drupal site and exported every content type, field, category and URL, along with traffic and inbound link data. Each item was tagged as keep, merge, rewrite, archive or leave behind. - Acceptance criteria against journeys
Criteria were written for each journey, not for each page. A page passed if a player could still find the game, and a candidate could still find the role. - Content model
We specified content types, fields, relations, categories and URL patterns, so a game page stayed a structured game page and did not become a flat post. - URL and redirect map
Every indexed URL, and every URL with inbound links, was mapped to its new address or marked as retired with a reason. - Language and search requirements
Linked English and Czech versions, fallback rules, and what site search should return were written as requirements, not left as cleanup after launch. - Roles and editorial workflow
We separated the people who publish news from the people who manage the structure of game pages, and defined review steps for each content type. - Non-functional requirements
We set requirements for performance during game update announcements, accessibility, security and plugin policy, analytics and cookie consent, and structured data for search engines. - Platform fit and migration mapping
WordPress content types, fields, templates and workflow were configured to the baseline, and a field-by-field mapping from Drupal to WordPress guided the migration scripts.
User journeys
Which journeys did the site have to support?
Audience
What they come for
What had to work after the move
Players
A game, its latest news and patch notes, and where to buy it
Reach any current game from the home page or search, then its news and store link, without dead ends
Modders
The engine, tools and the path into modding
Reach the engine page and follow a clear route to the modding documentation on the wiki
Press
Facts, assets and a contact
Find studio facts, game fact sheets, logos, screenshots and the press contact without signing in
Candidates
Open roles and what working at the studio is like
Find current roles, filter them by team or location, and reach the application form
Community members
The forums and wiki
Reach the community platforms from any game page and the main navigation
Content inventory
What did the content inventory show?
Content area
What we found
Decision
Game pages
Current titles structured differently from each other
Kept and rebuilt on one game content type with consistent fields
Older titles
Full pages for games no longer in active development, rarely visited
Moved into a compact retro games archive with short entries and store links
News
Years of posts, including duplicates and posts with no category
Kept, merged duplicates, and assigned each post to a game and a news category
Patch notes
Published as ordinary news, hard to find again
Kept as a news category linked to each game, so players can filter for updates
Careers
Role pages and general recruitment pages
Kept, with role details structured for filtering and an application link
Studio pages
About, history and culture pages with overlapping content
Merged into a smaller set of studio pages
Press materials
Assets scattered across news posts and attachments
Rebuilt as press kits for the studio and for each game
Campaign and event pages
Time-limited pages long past their date
Left behind, with redirects only where inbound links existed
Unused content types and fields
Types and fields with no content or no recent use
Left behind and recorded in the migration log
Content model
How was the content modelled?
The content model was the migration. Each type had defined fields, relations and a URL pattern, so the new site kept its structure instead of becoming a set of flat pages.
Content type
Key fields
Relations
URL pattern
Game
Title, short description, platforms, release status, key art, trailer, store links, community links
News, patch notes, press kit
/en/games/game-name
News post
Title, date, summary, body, featured image, category
One or more games
/en/news/post-title
Career role
Title, team, location, contract type, description, application link
Team and location categories
/en/careers/role-title
Studio page
Title, body, images
Related studio pages
/en/studio/page-name
Press kit
Fact sheet, logos, screenshots, videos, press contact
The studio or one game
/en/press/kit-name
Engine page
Overview, features, links to tools and documentation
Games built on the engine
/en/engine
Czech versions followed the same patterns under /cs/, with each translation linked to its English page.
Migration requirements
How were redirects, language and search specified?
Redirects
- Every old URL with traffic or inbound links was mapped one to one to its new address.
- Moved content returns a permanent redirect. Content left behind on purpose returns a "gone" response, or redirects to the closest relevant page where inbound links existed.
- No redirect chains: each old URL points straight to its final address.
- The redirect map was tested in full before cutover and monitored for missed URLs after launch.
Language
- English and Czech versions are linked as translation pairs, and each page tells search engines which language versions exist.
- If a Czech version does not exist, the language switcher leads to the English page instead of an error.
- Translation status is tracked for each item, so editors can see which pages are waiting for translation.
Search
- Game pages and guides rank ahead of older news for matching terms.
- Results can be filtered by game, content type and date.
- Common player terms, such as "mods" for modding, are mapped to the right content.
- Searches that return no results are logged, so editors can see what players are looking for and not finding.
Roles and permissions
Who could do what in the new site?
Role
Can do
Cannot do
Administrator
Configure the site, manage users, approve plugin changes
Not applicable
Web lead
Edit and publish any content, change game page structure and URLs
Install plugins without review
News editor
Create, edit and publish news and patch notes
Change game page fields, structure or URLs
Game page editor
Update game descriptions, media and links within the agreed fields
Change URLs, delete game pages or alter the template
Recruiter
Create, update and close career roles
Edit news, game or studio pages
Translator
Edit Czech versions and submit them for review
Publish without review
Contributor
Draft news posts and submit them for review
Publish content
Every content type moved through draft, review, scheduled and published states, and game pages needed a second review before publishing.
Acceptance criteria
What did the acceptance criteria look like?
Player finds a game
- Given a player is on the home page
- When they search for or select a current game
- Then they reach that game's page
- And can see its latest news and patch notes and a working store link
Candidate finds a role
- Given a candidate opens the careers section
- When they filter roles by team or location
- Then only open roles matching the filter are shown
- And each role links to its application form
Old link still works
- Given a URL from the old site has inbound links
- When someone opens it after cutover
- Then they are redirected in one step to the matching new page
- Or to the closest relevant page if the content was left behind
Language switch
- Given a reader is on an English page
- When they switch to Czech
- Then they see the Czech version if it exists
- And the English page with a notice if it does not
News editor cannot break a game page
- Given a user has the news editor role
- When they open a game page in the editor
- Then the game's fields, template and URL are read-only for them
Platform fit
How was WordPress fitted to the baseline?
WordPress came after the requirements, not before them. Each platform decision was checked against the baseline.
Content types and fields
Custom content types and fields were configured to match the content model, including relations between games, news and press kits.
Templates and blocks
The theme was built from the page templates the journeys needed. Game pages used locked layouts, and editors could only change the agreed fields.
Multilingual setup
The approach to translations was chosen against the language requirements, including linked pairs and fallback behaviour.
Search
Search was configured to the ranking, filter and synonym requirements.
Plugins
Each plugin had to meet a specific requirement and pass a security and maintenance review. Plugins that duplicated core features were not used.
Editorial workflow
Roles, review steps and scheduled publishing were configured to the roles matrix.
Cutover
How was cutover checked?
Cutover was checked against the acceptance criteria, not against a visual match of the old theme.
- Trial migrations. Content was migrated several times into a test environment, and each run was checked against the field mapping and the content inventory decisions.
- Content freeze. A short content freeze was agreed with marketing and community teams, timed away from game update announcements.
- Journey checks. Every journey in the acceptance criteria was run on the migrated site before go-live.
- Redirect test. The full redirect map was tested automatically, checking each old URL's target and response.
- Rollback plan. The old site stayed available until the new one had passed its checks in production.
- After launch. Missing pages, search coverage and zero-result searches were monitored daily in the first weeks, and any gaps were fixed through the redirect map or content updates.
Which BA techniques and tools did we use?
Techniques
- Stakeholder workshops
- Journey elicitation
- Analytics review
- Content inventory and audit
- Information architecture
- Content modelling
- Taxonomy design
- URL mapping
- Redirect specification
- Multilingual requirements
- Search requirements
- Roles and permissions matrix
- Editorial workflow modelling
- Given/When/Then acceptance criteria
- Non-functional requirements
- Source-to-target migration mapping
- Cutover planning
Tools
- Screaming Frog
- Google Analytics
- Google Search Console
- Miro
- Figma
- Jira
- Confluence
- Microsoft Excel
Results
What were the results?
- ~3 months of analysis before the build
- 5 audience journeys defined first
- 6 content types in the new content model
- 7 roles in the permissions matrix
A site built on a content model rather than a copy of the old pages.
Player, modder, press and candidate journeys verified at cutover.
- Old URLs redirected in one step, preserving years of inbound links.
- English and Czech versions linked properly, with clear fallbacks.
- Site search that returns games and guides ahead of old news.
- News editors able to publish quickly without being able to change game pages.
- A smaller, cleaner site, with unused content left behind on purpose and recorded in the migration log.
- A documented baseline the web team can use for future changes.
“
Lessons learned
What can other teams moving between CMS platforms learn from this project?
- Start with what the site is for, not with the old sitemap. The journeys decide what deserves to move.
- Treat the content model as the migration. Map fields and relations, not pages.
- Write redirects, language and search as requirements. Fixing them after launch costs traffic and trust.
- Separate the people who publish from the people who manage page structure. Routine updates should not be able to break key pages.
- Accept cutover against journeys, not against a visual match of the old site.
- Leave unused content behind deliberately, and record why.
Planning a move to a new CMS?
Talk to a senior business analyst about journeys, content models and redirects, before any template is built.
Bohemia Interactive: An Analysis-Led Move from Drupal to WordPress
