RAID Log
The RAID Log is a consolidated governance register that captures every Risk, Assumption, Issue, and Decision logged against a migration project. It gives project managers and stakeholders a single, structured audit trail of all the factors that could affect — or have affected — the project's outcome. Reviewed weekly in governance meetings, it keeps the whole team focused on what needs action and what has already been resolved.
Overview
The RAID Log brings together four of the most important categories of project governance into a single register. Risks are potential future problems that have not yet occurred — things that might go wrong and need to be monitored or mitigated before they materialise. Assumptions are statements your plan relies upon being true, such as "the target network will be provisioned before T-28" or "the application vendor will provide support during cutover." If an assumption turns out to be false, it often becomes an issue. Issues are problems that have already occurred and need active management — a firewall rule blocking replication traffic, a team unavailable for testing, or a missed dependency that wasn't in the original scope. Decisions are the formal choices made during the project that affect its approach, scope, or timeline, such as choosing to defer a DR site or agreeing to migrate in three waves instead of two.
By bringing all four types into a single register, the RAID Log avoids the fragmentation that occurs when teams maintain separate risk spreadsheets, decision logs in email threads, and issue trackers in different tools. Everything related to project governance is in one place, with a clear status on each item, an assigned owner, and a full history of changes. Project managers can filter the register by type, status, or impact to focus on whatever needs attention in any given meeting.
Migration projects are particularly prone to accumulating unresolved governance items because they span multiple teams, involve external dependencies, and operate under time pressure. A well-maintained RAID Log is one of the most reliable indicators of a project that is under control. It is not a bureaucratic exercise — it is a working tool used at every governance meeting to drive decisions and keep risks from becoming surprises.
When to use this
- Project kick-off: Capture the initial set of assumptions your plan is built on, and any known risks identified during scoping.
- Throughout the project: Log new risks and issues as they emerge — do not wait for the next governance meeting.
- Weekly governance meetings: Use the RAID Log as the structured agenda for reviewing open items, updating statuses, and assigning actions.
- Escalations: When an issue or risk needs to be raised with senior stakeholders, the RAID Log provides the documented evidence of what was known and when.
- Post-migration review: Review closed items to understand which risks materialised, which assumptions were wrong, and what decisions shaped the outcome. This feeds lessons-learned documentation.
Key features
Step-by-step instructions
Creating a RAID entry
Complete all required fields:
- Title — a short, clear description of the item
- Description — the full context, including what might happen, what has happened, or what was decided
- Owner — the person accountable for managing or resolving this item
- Impact — High, Medium, or Low
- Status — typically Open when first creating an entry
Optionally link the entry to a Migration Event if it affects a specific wave.
Updating an entry status
Filtering and exporting
Closing an entry
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Type | Required | The category of the entry: Risk (potential future problem), Assumption (something relied upon being true), Issue (problem already occurring), or Decision (key choice made). |
| Title | Required | A concise summary of the item — short enough to read at a glance in the register table, but specific enough to identify uniquely. |
| Description | Required | The full detail of the item. For Risks, explain what could go wrong and the consequence. For Issues, explain what has happened and the current impact. For Decisions, record what was decided and why. |
| Owner | Required | The person accountable for managing or resolving this item. Without an owner, nothing gets done. Every entry must have a named individual, not a team. |
| Status | Required | The current state: Open (active, unresolved), In Progress (being actively worked), Closed (resolved), or Accepted (risk acknowledged and accepted without mitigation). |
| Impact | Required | The severity of the item if it materialises or continues: High, Medium, or Low. Used to prioritise which items need attention in governance meetings. |
| Probability | Optional — Risks only | How likely the risk is to occur: High, Medium, or Low. Combined with Impact to assess overall risk exposure. Only shown for entries of Type = Risk. |
| Migration Event | Optional | Link this RAID item to a specific Migration Event (wave). Useful when a risk or issue is directly tied to an upcoming migration and should be visible to the event team. |
| Raised Date | Required | The date the item was logged. Defaults to today when creating a new entry. Important for tracking how long items have been open and for the audit trail. |
| Closed Date | Optional | The date the item was resolved, accepted, or closed. Set this when changing Status to Closed or Accepted so the register accurately reflects the resolution timeline. |
Example workflow
It is Monday morning and the project manager opens the RAID Log filtered to Type = Issue and Status = Open, ready for the weekly governance meeting. There are three open issues on the register.
The first issue — "Firewall rules blocking replication traffic from source VLAN to target VLAN" — was raised the previous week. The network team has now resolved it and confirmed replication is flowing. The PM updates the Description to note the resolution, sets Status to Closed, and records today's date in the Closed Date field. The second issue — "Vendor unable to confirm application support window for cutover weekend" — is still being chased. The PM leaves it as In Progress and adds a note to the Description: "Escalated to account manager on Friday — awaiting written confirmation." The third issue is new: the security team has raised a concern that the target environment's vulnerability scanning is not yet complete. The PM updates the Impact to High and reassigns the Owner to the security team lead to drive resolution before the next governance meeting.
With Issues reviewed, the PM switches the filter to Type = Risk and Status = Open. There are five open risks. The PM works through each one, checking whether the probability has changed since last week. One risk — "Key migration engineer leaves project before completion" — has reduced in probability now that the engineer has confirmed their availability through to project close. The PM updates the Probability from High to Low and adds a note. The remaining four risks are unchanged and no action is needed this week.
The meeting closes with all RAID items reviewed in under 20 minutes because the register was up-to-date going in. The export function is used to attach the current Open register to the steering committee pack for the following day.
Tips & best practices
A RAID Log that is only updated when something goes badly wrong is not a governance tool — it is just a post-incident record. The real value comes from reviewing open items weekly, keeping statuses current, and reassigning ownership when people change. Make the RAID Log the first agenda item in every governance meeting, not an afterthought.
The Title field is just a label. The Description is where the real information lives — what exactly is the risk, what has happened with the issue, what was decided and why. Write enough detail that someone picking up the RAID Log for the first time can understand the item without asking anyone. Include dates of key actions taken and names of people involved.
If a risk or issue is specifically tied to an upcoming migration event — for example, an unresolved firewall issue that affects Wave 2 — link it to that Migration Event using the Migration Event field. This surfaces the open item when reviewing the event's readiness, and ensures it cannot be overlooked during go/no-go assessments.
Common mistakes
The most common failure mode for a RAID Log is an ever-growing list of open items where nothing is ever closed. If items are never reviewed, owners stop taking them seriously, and the register becomes noise rather than signal. Set a regular cadence — weekly at minimum — to review every open item and either progress it, reassign it, or close it. A stale RAID Log gives false assurance that risks are being managed when they are not.
An item with no owner, or with a team rather than an individual named as owner, will not get resolved. "The networking team" owns nothing — a named person owns things. Every RAID item must have a specific individual assigned who is accountable for driving it to closure. If you cannot name an owner, that itself is an issue to resolve before logging the item.
A Risk is something that has not yet happened but might. An Issue is something that has already happened or is actively occurring. This distinction matters because they require different responses: risks need mitigation planning and monitoring, issues need immediate action and escalation. Logging an issue as a risk delays the response. If in doubt, ask: "Has this happened yet?" If yes, it is an Issue.
Many project teams use the RAID Log purely as a risk register and neglect Assumptions and Decisions entirely. This is a missed opportunity. Undocumented assumptions are one of the leading causes of mid-project scope disputes — if you assumed the target environment would be ready by a certain date and it is not, having that assumption documented protects the project team and drives accountability. Undocumented decisions cause confusion when team members forget what was agreed or the rationale behind it. Log all four types consistently.