Intranet project checklist: from business case to launch

There is a lot to keep track of when launching an intranet: who looks after the policy library, how employee access works, and who will provide support once everyone starts using it. This intranet project checklist helps your team work through those questions before they become last-minute surprises.

Use it to plan an Open Intranet deployment, check how the product meets employee needs, and see what is ready and what still needs attention. Start with existing capabilities and configuration. Add integrations or extensions only where an agreed requirement remains unmet.

In this article:

How to use this checklist
1. Confirm the business problem and project mandate
2. Understand employees and their access needs
3. Set up ownership and decision-making
4. Approve the budget and delivery scope
5. Validate Open Intranet against the requirements
6. Confirm hosting, contracts, and operational control
7. Define identity, access, and privacy requirements
8. Audit content and define publishing governance
9. Validate navigation, search, and key journeys
10. Configure the first-release features
11. Connect and test the required systems
12. Prepare environments and recovery procedures
13. Migrate and approve launch content
14. Complete acceptance testing and the employee pilot
15. Prepare employees and authorize launch
16. Operate, improve, and retire the old intranet
Turn the checklist into an implementation plan

How to use this intranet project checklist

Copy the checks into your project tracker or a shared spreadsheet. Each of the 16 phases contains six checks, giving you 96 checks in total.

These columns are a useful starting point:

Check	Owner	Due date	Status	Supporting document or decision
Action to complete	Person responsible	Agreed date	Current status	Approval, test result, or document

Use five status values: not started, in progress, blocked, done, or not applicable.

Before ticking a check as done, make sure the person responsible can point to the agreed result. If something does not apply, note why and who agreed. Keep optional features optional: decide which ones you need, then configure and test only those selected.

You do not need to finish each phase before starting the next. Content auditing, hosting reviews, and product evaluation can run alongside one another where their dependencies allow. Each phase ends with a short reminder of what to have ready.

Leave room for a final launch decision. Even when planning is on track, your team still needs to review blockers, agree which risks it can accept, and decide who can authorize a rollback.

1. Confirm the business problem and project mandate

Start by agreeing what you want the intranet to improve before moving into configuration, migration, or development.

Document the employee problems the intranet must solve, with examples collected from the organization.
Agree which problems belong in the intranet and which remain with existing business systems.
Name an executive sponsor with authority to approve funding and resolve cross-team disputes.
Assign one accountable intranet owner and confirm the time they can commit before and after launch.
Define measurable outcomes, baseline measurements, and a named owner for each measurement.
Approve a project brief covering scope, constraints, expected outcomes, and the reason for the target launch date.

Make “easier policy access” something you can check together. For example, ask employees from different teams to find the current travel policy and identify who approved it. Note how long it takes, where they get stuck, and whether they find the correct version. Repeat the same test after launch. Page views alone will not tell you whether the task became easier.

It also helps to separate finding information from completing a transaction. The intranet might explain an expense process and link to the finance system without replacing that system.

Use the intranet business case guide to connect employee problems to funding decisions.

What to have ready: An approved project brief and a plan for measuring your starting point.

2. Understand employees and their access needs

Make sure the first release works for the people expected to use it, not just the project team.

Identify employee groups by role, location, language, work pattern, and access to a company device.
Talk with or observe employees from office, remote, frontline, and other relevant groups.
Rank the tasks employees need to complete, such as finding a policy, locating a colleague, or submitting a request.
Record barriers involving shared devices, personal phones, unreliable connections, or lack of company email.
Document language and accessibility needs and include affected employees in planned testing.
Check the proposed first-release tasks with people from the groups expected to use them.

Remember that not everyone has a laptop, corporate mailbox, or the same working hours. A frontline employee using a shared terminal has different login, privacy, and support needs from someone using a company laptop at home.

For each important task, note who needs to do it, how they will reach the intranet, what a good result looks like, and what might get in their way. This gives your team a practical starting point for setting up access, testing the experience, and explaining the new intranet to employees.

What to have ready: A picture of your employee groups and a ranked list of the tasks that matter most to them.

3. Set up ownership and decision-making

Give everyone a clear point of contact and agree who makes which decisions, so work can keep moving.

Name representatives from IT, internal communications, HR, and the business areas affected by the rollout.
Identify when security, privacy, procurement, legal, and employee representatives need to participate.
Assign responsibility for product decisions, delivery, content, integrations, testing, and ongoing support.
Agree who approves requirements, budget changes, launch readiness, and exceptions.
Agree how often to meet, where to record decisions and risks, and who to turn to when work gets stuck.
Reserve time for content owners, employee testers, administrators, and other internal contributors.

Go one step beyond naming a department: choose a person for each workstream who can make decisions or get the right approval.

Keep decision notes short but useful: the question, options considered, decision, approver, date, and affected requirements. Agree who can help resolve a blocked decision so the team does not have to keep chasing it informally.

What to have ready: A clear list of responsibilities, decision-makers, and the time each contributor can commit.

4. Approve the budget and delivery scope

Plan for both getting the intranet live and looking after it once employees start using it.

Estimate initial costs for setup, configuration, integrations, migration, training, and any agreed extensions.
Estimate recurring costs for hosting, support, updates, content operations, and third-party services.
Include internal staff time and a contingency with an agreed approval process for using it.
Define what is included in the first release, what is deferred, and what is explicitly excluded.
Agree milestones with dependencies, owners, and acceptance criteria rather than dates alone.
Approve both the implementation budget and an operating budget with named budget holders.

Open Intranet is an Open Source system built on Drupal. There are no per-user software licensing fees, but running costs still need a place in the budget. Allow for hosting, maintenance, editorial work, support, and any paid external services. Review the Open Intranet pricing information alongside your internal staffing estimates.

Give each milestone a clear meaning. “Pilot ready” should mean that agreed content, employee access, and test scenarios are ready, not simply that the scheduled week has arrived.

What to have ready: A funded delivery plan and multi-year budget, with assumptions and budget owners recorded.

5. Validate Open Intranet against the requirements

Before planning new development, explore what the product can already do for your team.

Turn each must-have requirement into a scenario that can be demonstrated and tested.
Review those scenarios in an Open Intranet demo or evaluation installation using representative content.
Classify each requirement as available, configurable, dependent on an additional module or integration, or requiring an extension.
Verify the availability and release status of proposed features rather than treating experimental or pre-release features as launch-ready.
For each remaining gap, decide whether to change the process, configure an existing capability, add a supported component, extend, or defer.
Approve the review of what fits and what is missing, along with costs, maintenance responsibilities, and acceptance criteria for each proposed extension.

Start with the Open Intranet product documentation and try your highest-priority tasks in the version you plan to deploy. The goal is to check a configured product against your needs, not commission every feature from scratch.

For example, replace “supports restricted documents” with a scenario: an authorized employee can find and open a document, while an unauthorized account cannot access it through search or a direct link.

Use the intranet requirements resource to organize the comparison. Note the tested version, setup assumptions, results, and decisions still to make.

Allow time to configure and test identity integrations in your own environment. Likewise, self-hosting still needs to be reviewed against your security and regulatory obligations.

What to have ready: An approved comparison of your requirements and product capabilities, with a decision for each remaining gap.

6. Confirm hosting, contracts, and operational control

Make sure your team knows how the intranet will be run, what is included, and who to contact for help.

Choose a hosting approach based on organizational requirements and assign responsibility for running it.
Document the planned locations of application data, backups, logs, and relevant external processing.
Review implementation deliverables, exclusions, acceptance terms, support coverage, and ongoing charges.
Confirm organizational access to code repositories, configuration, data exports, hosting accounts, and administrative credentials.
Document any paid third-party dependencies, usage charges, renewal terms, and service limitations.
Agree a handover and provider-change process, including exports, documentation, credentials, and transition assistance.

Choose hosting around your actual needs: data locations, the people available to run it, recovery targets, access controls, and support coverage. Remember to include any external email, analytics, or search processing you select, not just the main application server.

One distinction is worth keeping clear: software access rights and copyright ownership are different. Open Source licenses grant rights under their terms; they do not transfer exclusive ownership of all community-contributed code. Contracts should state the rights and handover arrangements for project-specific work.

What to have ready: An approved hosting choice and written agreements covering responsibilities and services.

7. Define identity, access, and privacy requirements

Make sure employees can reach the information they need while keeping sensitive information with the right people.

Approve an access matrix covering employees, editors, administrators, contractors, and sensitive content areas.
Choose the identity provider and login approach and document the configuration or integration work required.
Define account creation, role changes, account removal, and the handling of existing sessions when access is revoked.
Agree authentication, session, shared-device, and emergency administrator-access requirements with the security owner.
Identify personal and sensitive data and obtain the relevant owners’ decisions on collection, visibility, retention, and deletion.
Agree requirements for security logging, access reviews, incident response, and handling employee data requests.

Review the Open Intranet user administration documentation when mapping roles and identity options. Check the chosen approach against your identity provider, deployment, and employee groups.

Include account removal in your tests. After disabling an account in the connected identity system, check what happens to an employee who is already signed in to the intranet. Agree how quickly that access should end, then test it.

Use these checks to guide the conversation with your security, privacy, and legal colleagues. They still need to approve the requirements for your deployment; the checklist is not legal advice or a guarantee of compliance.

What to have ready: An approved plan for who can access what, together with the agreed security and privacy requirements.

8. Audit content and define publishing governance

Give the new intranet a useful, well-organized starting point, with someone looking after each content area.

Inventory existing pages, files, knowledge sources, and repositories, including their owners and intended audiences.
Classify each content set as migrate, rewrite, archive, delete subject to retention approval, or keep in its existing system.
Assign an owner and next review date to every content area included at launch.
Agree content types, required metadata, naming conventions, and document version rules.
Document the draft, review, approval, publication, correction, and retirement process.
Approve editorial guidance and accessible templates for the content types needed in the first release.

You do not need to bring every old file with you. Start with the material employees need for first-release tasks. Ask content owners to resolve conflicting policies and duplicate documents before import.

Use the document administration documentation to compare your publishing rules with available configuration. Where information stays in another system, make it clear how employees will find the current, approved version.

What to have ready: A content migration list, named owners, and agreed publishing rules.

Help employees find useful information without needing to know the organization chart by heart.

Organize proposed navigation around employee tasks and validate the labels with intended users.
Agree the homepage priorities and the content different audiences need to see first.
Define taxonomy, metadata, filters, and the content sources that search should include or exclude.
Prepare representative search queries with expected useful results and examples of restricted results that must remain hidden.
Test key journeys in a configured evaluation site before commissioning unnecessary interface changes.
Record mobile and accessibility acceptance criteria and resolve navigation problems identified during early testing.

Start with the existing interface and Open Intranet navigation configuration. Try those options with employees first, then prototype additional behavior where an unresolved need justifies it.

Use the words employees would actually type, not just exact document titles. For example, check whether “time off” leads to the relevant leave guidance. Also check that restricted information stays out of result titles, snippets, and other previews for unauthorized accounts.

What to have ready: Tested navigation and a set of employee tasks and searches, with clear expected results.

10. Configure the first-release features

Focus the first release on what employees need most. Other useful features can follow later.

Configure branding, homepage layouts, navigation, and reusable page templates for the agreed audiences.
Configure the selected news, knowledge, document, and people-directory capabilities and their content owners.
Decide whether events, forms, social interactions, acknowledgments, and other optional features belong in the first release.
Configure selected workflows, notifications, audience targeting, and moderation rules and test their recipients.
Configure selected languages, profile fields, and visibility settings using representative employee accounts.
Review every proposed code change against available configuration options and document approved exceptions.

Apply these checks to the capabilities you have selected and verified for your planned release. Some options may need additional components or work.

Keep a note of which optional features you are including and which you are leaving for later. There is no need to configure and test a feature you have decided not to use. For those included, confirm availability, dependencies, permissions, and acceptance criteria first.

For notifications, check who receives the message, what information it reveals, and where its links lead. For profiles, sign in as an ordinary employee to check field visibility, rather than relying on the administrator view.

What to have ready: A record of the configuration and test results for the features in your agreed scope.

11. Connect and test the required systems

Check that information moves reliably between your systems and that someone is ready to help if it stops.

List each launch-critical integration, its system owner, purpose, and approved implementation approach.
Agree the source of truth, field mappings, direction of transfer, and update frequency for each data flow.
Obtain required credentials and permissions and document how secrets are stored and rotated.
Test successful transfers and failures, including duplicate records, missing fields, stale data, and unavailable services.
Confirm who receives failure alerts, who resolves incidents, and how missed updates are recovered.
Document monitoring, ongoing costs, and responsibility for testing future changes to connected systems.

Agree which system to trust when values conflict. If employee department data comes from an HR system, decide whether intranet edits are blocked, overwritten, or handled through an agreed exception process.

Use realistic sample data or appropriately protected data in test environments. Keep sensitive live records out of a test installation unless their use has been properly reviewed and protected.

If no integrations are needed for launch, simply record that decision and its approval. This makes it clear that the team considered the question rather than overlooked it.

What to have ready: A list of integrations and approved test results, or agreed reasons for leaving them out.

12. Prepare environments and recovery procedures

Give your team a repeatable way to release updates and a tested plan for getting the intranet back if something goes wrong.

Establish separate environments for configuration/testing and production, with appropriate access restrictions.
Document and rehearse the process for moving approved configuration and code into production.
Configure the domain, encrypted connections, outbound messages, scheduled jobs, and search infrastructure required by the deployment.
Set up monitoring for availability, errors, capacity, background jobs, and critical integrations with named alert recipients.
Agree recovery targets and demonstrate a restore from backup in a controlled environment.
Document update testing, security patch responsibilities, incident escalation, and deployment rollback procedures.

Agree how much data loss and downtime the organization can accept. Use those targets to decide how often to back up, how long to keep backups, and how to restore them.

Test the restore, not just the backup. Restore the required database, files, and configuration, then check access and key employee tasks. Note how long it takes and which steps need to be done manually.

Restrict outbound messages in test environments so rehearsals do not accidentally notify employees. Keep instructions for reversing a deployment separate from those for recovering the full service.

What to have ready: A practical operating guide, a successful restore test, and named people responsible for running the service.

13. Migrate and approve launch content

Move the approved content into its new home and check that employees will find the right version.

Map source content, files, metadata, ownership, and permissions to their destination structures.
Run a trial migration covering representative content types, documents, and access restrictions.
Check migrated content for missing files, broken links, duplicate records, formatting problems, and incorrect permissions.
Have content owners approve rewritten and migrated launch content, including key policies and help pages.
Agree the content freeze, final update process, cutover responsibilities, and fallback plan.
Define redirects, archive access, and the retirement plan for old publishing locations so employees know which version is authoritative.

Compare what you expected to move with what actually arrived. Note what moved, what failed, what was deliberately left out, and what needs manual correction. Record counts can help spot missing material, but remember to check permissions, links, and the content itself too.

Your launch transition plan should explain how changes made after the trial migration reach the live site. Agree who can publish during the content freeze and how to handle urgent corrections.

What to have ready: Checked migration results, content-owner approval, and a plan for the final move.

14. Complete acceptance testing and the employee pilot

Invite employees to try the intranet in the conditions they will actually use it, and check the results against your agreed requirements.

Demonstrate that every launch-critical requirement passes its agreed acceptance test.
Test permissions with allowed and disallowed accounts, including direct file links, search results, and notifications.
Test login, account removal, mobile use, supported browsers, keyboard navigation, and relevant assistive technologies.
Test performance against agreed usage scenarios and record results against the accepted thresholds.
Run a pilot with representative employees and record task completion, feedback, and support issues.
Resolve launch-blocking defects and obtain written decisions, owners, and deadlines for accepted remaining issues.

Try tasks as an ordinary employee, not just as an administrator. Include different roles and access conditions, such as restricted accounts and shared devices where relevant.

Agree performance scenarios before running tests: expected concurrent activity, common page visits, searches, and document access. Note the environment and dataset so the team can understand what the results cover.

Keep fixes and new ideas on separate lists. A failed launch-critical requirement needs a fix and another test; a useful enhancement can wait in the later backlog without quietly expanding the first release.

What to have ready: An acceptance report and pilot decision, including approvals for any issues that remain.

15. Prepare employees and authorize launch

Help employees feel ready for the change, and bring the team together for a clear launch decision.

Train editors, administrators, and support staff and confirm they can perform their assigned tasks.
Prepare employee guidance explaining where to sign in, what has moved, why to use the intranet, and where to get help.
Plan launch communications for all relevant groups, including employees outside corporate email channels.
Assign launch-day and early-support coverage, a feedback route, and incident escalation contacts.
Confirm that content, access, recovery, integration, testing, and operational owners have supplied their readiness evidence.
Hold a documented go/no-go review covering blockers, accepted risks, cutover timing, rollback triggers, and who can authorize rollback.

Give people a chance to practise during training. Ask editors to publish and correct content, administrators to complete assigned account tasks, and support staff to work through a realistic access issue.

Choose communication channels employees can actually reach. Depending on the organization, these may include supervisor briefings, shift handovers, printed sign-in instructions, or existing workplace channels.

At the go/no-go review, share the relevant test results and approvals rather than just completion percentages. Record who made the decision and when, which risks were accepted, and what would cause the team to stop or reverse the launch.

What to have ready: An approved launch decision and a transition plan with people assigned. Let readiness, not just the calendar, guide the final decision.

16. Operate, improve, and retire the old intranet

Keep listening after launch, look after the service, and retire the old tools when your team is ready to let them go safely.

Confirm after cutover that employee access, key tasks, integrations, notifications, and monitoring work in production.
Review early support requests and employee feedback and assign owners to recurring problems.
Compare agreed success measures with their baselines and schedule subsequent reviews.
Put content reviews, access reviews, patching, recovery tests, and capacity checks into the operating calendar.
Maintain a prioritized improvement backlog and review costs and support needs before adding new features.
Retire the old intranet and redundant services only after owners approve retention, archive access, redirects, and contract closure.

Return to the employee task tests you set up in the business case. If policies are still hard to find, look at search terms, duplicate content, navigation, and permissions before deciding another feature is the answer.

Use an intranet health check to guide later conversations about what is working and where employees still need help. Prioritize improvements by business impact, evidence, cost, and ongoing support needs.

There is no need to rush the retirement of the old platform. It may happen after the early-support period. Confirm archive access and retention decisions before removing infrastructure or closing contracts.

What to have ready: A completed handover, scheduled reviews, and approval to retire the old system. Launch is a milestone; looking after the intranet continues.

Ready to turn the checklist into an implementation plan?

Bring this checklist, the employee tasks that matter most to your team, and your integration requirements to an Open Intranet demo.

Together, we can explore what can be configured, what needs connecting, and which remaining gaps genuinely require development. You will have a clearer starting point for scope, costs, responsibilities, and launch readiness before committing to a delivery date or budget.