Why assess first
A migration plan is only as accurate as the picture it is based on. Many organizations discover midway through a project that a system did more than anyone thought, or that an important report depended on a file on someone’s desktop. A current state assessment is the structured effort to find these things before they become surprises.
The assessment does not need to be exhaustive or perfect. It needs to be good enough to support honest scope, effort and risk estimates, and to show where the unknowns are.
What to inventory
Systems and applications
List every system in scope, including the obvious ones and the less visible ones. For each, record:
- Name, purpose and business function it supports.
- Who owns it, who administers it and who uses it.
- Where it runs and how it is supported.
- Contract, licence or support end dates, where relevant.
- Known problems or limitations.
Do not forget small tools, departmental databases and anything bought outside the central IT process. Unofficial software is often where the least-documented knowledge sits.
Data
For each system, understand what data it holds and in what shape:
- Main record types and approximate volumes.
- Quality, as far as it is known, including known duplicates and gaps.
- Sensitivity: personal, financial or confidential data may need extra care.
- How long data must be kept and who decides. Existing data retention schedules, if they exist, are a useful input.
- Where copies exist, such as exports, backups and extracts.
Integrations and interfaces
Map how systems exchange data. Note direction, frequency, format and method, and what happens if an interface fails. Include scheduled file transfers, manual exports and imports, and reports pulled by other systems. This is the area where missed items most often cause trouble after go-live, so the check against system interoperability needs in the target should be made early.
Reports and outputs
List the reports, dashboards and extracts that people actually use, and who relies on them. Many reports are rarely opened, but a few are critical to a monthly or yearly task, such as a financial close process. Ask the users, not just the system owners, which they would notice missing.
Users, roles and access
Record who has access and at what level. This will feed the access design in the new system and gives an opportunity to clean up old accounts. Concepts such as role-based access control and the least privilege principle are relevant when deciding how access should look afterward.
Processes and informal workarounds
Document how work is done in practice, not only how a procedure says it should be. Look especially for:
- Spreadsheets that bridge gaps between systems.
- Manual re-keying of data from one place to another.
- Checks performed by one experienced person from habit.
- Local rules or exceptions that are not in any manual.
- Email-based approvals or shadow records.
Workarounds point to needs the current system does not meet. If the new system does not address them, they will reappear. Spreadsheet systems in particular can hold significant logic and data that deserve a closer look.
How to gather the information
No single method finds everything. Combining several works better:
- Documents and diagrams. Start with what exists, but assume it is partly out of date.
- System-level evidence. Administrators can often list interfaces, scheduled jobs, user accounts and storage use.
- Interviews. Talk to people at different levels, including those who do the daily work. Ask what they do on a bad day, what they do at month end and what they do when the system is unavailable.
- Observation. Watching someone work for an hour can reveal steps they would never think to mention.
- Sampling data. Looking at actual records tells you more about quality than any description.
Stakeholder mapping can help decide whom to talk to, so that quieter users and support staff are not overlooked.
Turning findings into a usable output
Gather the results into a form that others can read and challenge:
- A system inventory table.
- A dependency map showing what connects to what.
- A data summary with volumes, quality notes and sensitivity.
- A list of workarounds and unknowns, each with a proposed owner.
- A risk list noting anything that looks hard, fragile or undocumented.
Share the draft with the people who contributed and ask what is missing. Corrections at this stage are cheap.
Establish a baseline too
While assessing, note how the current setup performs: how long key tasks take, how many support requests arise, how often errors occur. Without a performance baseline, it is hard to say later whether the new system improved anything. Only record measures you can define clearly and capture consistently.
Common pitfalls
- Relying on a single source, such as the IT department’s list, and missing business-owned tools.
- Treating the assessment as a one-off. Things change during a long project, so revisit it before key checkpoints.
- Ignoring the “why”. Recording what a system does without asking why a feature exists can lead to removing something that mattered.
- Letting it drag on. Set a time limit and a depth appropriate to the risk. The goal is a reasonable plan, not a perfect catalogue.
A good assessment leaves the project team with a shared, honest picture, including a clear list of what is still not known.