Data Assessment: Discovery Guide
How we assess data before a DWH migration or a green-field DWH build.
The document is intended for internal use by the sales and solution architecture teams during the discovery phase. This guide explains the purpose, process, and expected outcomes of an Aliz Data Assessment.
note
This is the current official version of the Data Assessment: Discovery Guide. If you have any feedback or suggestions for improvement, use this working document: Data assessment process | Discovery Guide
0. How to use this document
- Before the first client call: read sections 1–3. They cover what the assessment is, why it comes first, and how we run it.
- During the call: use section 8 (qualifying questions) to size the assessment, agree on how deep it should go (section 1.4), and use section 5 (what we need from the client) to set expectations early.
- After the call: send the client the survey workbook (section 9) and the roles-and-access list (sections 5.1 and 5.3). Book the kick-off.
Key message for the client: "Before we estimate a migration or design a new platform, we spend a few weeks getting the facts right: what data you have, how it moves, who uses it and what it costs. At the end you have a roadmap, a target architecture and an estimate you can defend internally, whoever you pick to build it."
1. What the assessment is, and why it comes first
1.1 In one paragraph
A data assessment is a short, fixed-scope engagement, typically 4–6 weeks at standard depth. Lighter and deeper variants exist (section 1.4). We map the client's current data landscape (sources, warehouse, pipelines, reports, consumers, infrastructure, security, operations), find out what the business needs from it, and turn that into a target architecture on Google Cloud, a migration or build strategy, a phased roadmap and a costed first step (PoC or pilot).
1.2 Why clients should do it before the actual project
How far each point goes depends on the depth agreed for the assessment (section 1.4).
| Without an assessment | With an assessment |
|---|---|
| The estimate rests on assumptions, so the contingency is large or change requests pile up later | The estimate rests on an inventory of objects, jobs and reports, plus measured volumes |
| Hidden dependencies (an Excel macro, a nightly export to a partner, a report nobody documented) come to light during cutover | The main upstream and downstream dependencies are known before anything moves. The undocumented processes and workarounds are at least estimated in volume, and mapped in full at a deep level. |
| Everything gets migrated "as is", including tech debt and unused data | Workloads get a recommendation (migrate as is, re-platform, refactor or retire): by system group at light depth, individually for tier-1 at standard, and for every workload at deep (section 1.4). Unused data and reports are flagged for retirement. |
| A PoC and an iterative plan are still possible, but their contents rest on assumptions | The PoC and the increments are chosen from evidence, so business value comes earlier and is better targeted |
| Security, network and compliance blockers surface late | Security and infrastructure teams are involved early in the assessment, as their availability allows. Their blockers (often the slowest items, such as access and network) go into the plan. |
1.3 Two flavours of the same process
The process is the same in both cases. The emphasis shifts:
| Migration assessment (an existing DWH moves to GCP) | Green-field assessment (new DWH or lakehouse on GCP) | |
|---|---|---|
| Main question | How do we move what exists, safely, and improve it on the way? | What should we build first, and on what foundations? |
| Heaviest workstreams | Inventory of the existing DWH, SQL and ETL complexity, dependency mapping, cutover and parallel-run strategy, data validation | Business use cases and KPIs, source system analysis, data model and domain design, governance, BI strategy |
| Automated evidence | Metadata and query-log extraction from the legacy DWH (see section 4), SQL translation dry runs | Source system profiling, volume and freshness measurement |
| Typical extra output | Wave plan, workload decisions at the agreed granularity (migrate / re-platform / refactor / retire), parallel-run and decommissioning plan | Use-case prioritisation, domain and data-mart design, MVP scope |
| Common pitfall | "We know our system": documentation is out of date and the real logic sits in code nobody owns | Scope drifts toward "everything"; business priorities are unclear |
Most real engagements are a hybrid: some legacy is migrated and some new sources and use cases are added.
1.4 Assessment depth: how much certainty the client buys
How granular the results are depends on the depth of the assessment and the complexity of the landscape, not only on the process. We agree on the depth at scoping and write it into the offer, so both sides know what the report will and will not contain.
| Light | Standard | Deep | |
|---|---|---|---|
| Typical duration | 2–3 weeks | 4–6 weeks | 2–3+ months |
| Inventory | Main systems and volumes | Full inventory of tier-1 systems, sampled for the rest | Full inventory |
| Dependencies | Major flows, plus an estimate of undocumented processes and workarounds | Mapped for tier-1 workloads, sampled for the rest | Mapped in full |
| Workload decisions (migrate / re-platform / refactor / retire) | By domain or system group | Individually for tier-1 workloads, by group for the rest | Per workload |
| Estimate | Range (e.g. ±40%) | Wave 1 firm, later waves as a range | Per wave |
| Good fit when | Budget or timing is tight, an early go/no-go decision, input to an RFP | Most migrations: enough detail to plan and start wave 1 | Complex or regulated estates, fixed-price delivery, a hard cutover deadline |
Durations and confidence levels are placeholders, to be calibrated against recent engagements (section 10).
The report always states its confidence: what was fully assessed, what was sampled and what was estimated. Landscape size (section 8.2) and depth together determine the duration. A large estate at a deep level can take longer than the table suggests.
2. Our principles (what sets our approach apart)
These points show know-how in a client conversation. Each one comes from past engagements.
- Evidence, not just interviews. We back interviews with hands-on checks: metadata extracts, query logs, job lists, orchestrator versions, BI usage statistics. People forget things; logs don't.
- Business first, technology second. Every source and pipeline is tied to a business use case or KPI. That tie decides the order of the roadmap.
- Incremental value. We don't recommend big-bang migrations. The roadmap is built from increments that each deliver something usable, with a PoC or pilot as the first milestone.
- Raw first, ELT by default. We land data as close to the source and as granular as possible, then transform it inside the platform. One raw layer can then serve several consumers (group-level reporting, domain data marts, ML) without separate pipelines for each.
- Governance-ready by design. We always assess governance needs (ownership, PII, access, quality, retention, DR) and design the platform so governance can grow with it. Ownership, PII tagging and the access model are designed in from the start, because they are expensive to retrofit. How much more we implement, and when, follows the client's priorities.
- Options, not dogma. For key decisions we present two or three architecture alternatives with pros and cons, and record the choice as an Architecture Decision Record (ADR).
- Candour about tech debt. We say it when something should be retired rather than migrated, or when a "black box" needs reverse engineering first. It is cheaper to hear this during the assessment than in month 6.
- Reusable output. The deliverables are the client's to keep. They are detailed enough to build an RFP on, or to hand to any implementation team.
3. The process
3.1 Overview
Phase 0 Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Prepare → Kick-off → Discover → Analyse & design → Review & refine → Readout & handover
(before T0) (week 1) (weeks 1–3) (weeks 2–4) (weeks 4–5) (week 5–6)
interviews + survey current-state report draft discussed final report
+ hands-on checks target options with client roadmap + PoC plan
Phases 2 and 3 overlap on purpose: we start analysing as soon as the first inputs arrive, which surfaces gaps early.
Typical timeline: 5 weeks for a mid-size landscape at standard depth. Sections 1.4 and 8.2 give depth and sizing guidance. Our reference retail assessment (Auchan Hungary) ran for 5 weeks with the same structure: discovery → design → demonstration.
3.2 Phase by phase
Phase 0 — Prepare (1–2 weeks before kick-off)
| Goal | Start in week 1 with access, people and the first inputs already in place. |
|---|---|
| Aliz activities | Agree on scope and objectives. Send the survey workbook and the access list. Propose the interview schedule. Sign the NDA or DPA if needed. |
| Client inputs | Named project coordinator. Sponsor sign-off on scope. Access requests started (these usually take the longest). First pass at the survey: at least Overview, Foundations and the Datasource catalog. |
| Exit criteria | Kick-off date fixed. Interview slots booked for weeks 1–2. Access requests submitted. |
Sales tip: delayed access is the #1 cause of assessment delays. Raise it on the first call and ask who approves access in their organisation.
Phase 1 — Kick-off and mobilisation (week 1)
| Goal | Shared understanding of the goals, scope, success criteria and ways of working. |
|---|---|
| Aliz activities | Kick-off workshop covering team, goals, timeline, interview schedule, deliverables and prerequisites. Agree on communication cadence (weekly status and a shared channel). Confirm scope boundaries: what is in, what is out, how we treat "dark data". |
| Client inputs | Sponsor, coordinator and key technical leads at the kick-off. Architecture diagrams and existing documentation shared. |
| Output | Kick-off deck with agreed goals and success criteria. Confirmed interview plan. RACI. |
Phase 2 — Discovery (weeks 1–3)
We run three parallel tracks to see the landscape as it really is:
A. Interviews (structured, 60–90 minutes each)
| Interview | Typical client participants | Focus |
|---|---|---|
| Business and strategy | Sponsor, business owners, key report users | Drivers, pain points, KPIs, priority use cases, success criteria |
| Data platform / DWH | DWH lead, data engineers | Architecture, data model, volumes, history, known issues |
| Pipelines and orchestration | ETL developers, platform engineers | Tools, number of jobs, schedules, dependencies, failure handling, complexity, design patterns |
| Source systems | Owners of the main source systems (ERP, POS, CRM, e-commerce…) | Interfaces, extract methods, change frequency, environments, constraints |
| BI and reporting | BI lead, power users | Tools, report inventory, users, freshness needs, ad-hoc analysis habits, currently unfulfilled needs |
| Infrastructure and network | Infra and network team, cloud team | Hosting, connectivity (VPN or Interconnect), bandwidth, existing GCP footprint |
| Security and compliance | CISO or IT security, DPO | PII, GDPR, encryption, identity, access model, audit, data residency |
| Operations | Ops / SRE, support | SLAs, monitoring, incidents, DR (RPO/RTO), release and change process |
B. Survey workbook. The client fills in the structured catalogues: sources, pipelines, consumers and BI (section 9). We fill in the gaps together during interviews.
C. Hands-on checks (read-only access, ideally in weeks 1–2)
- Asset inventory and metadata harvest. Schemas, tables, views, stored procedures, sizes, row counts, growth.
- Legacy DWH workload analysis (migrations). Query logs and metadata are extracted with Google's
dwh-migration-dumperand run through the BigQuery migration assessment (section 4). - Pipeline and orchestration audit. Job inventory, schedules, custom operators and plugins, orchestrator versions (e.g. Airflow 1.x vs 2.x or later), dependency graph.
- Data profiling on a sample of key tables. Volumes, ingestion velocity, data types, quality hot-spots.
- BI usage analysis. Which reports are really used, by how many people and how often. This is often where we find reports that can be retired.
- Architecture validation. We compare the documented architecture with what we find in the systems.
- Cost baseline. Current licence, infrastructure and operations costs (inputs to the TCO comparison).
Phase 3 — Analysis and target design (weeks 2–4)
| Goal | Turn the findings into decisions. |
|---|---|
| Aliz activities | Current-state documentation. Dependency analysis (upstream producers, downstream consumers). A decision per workload or system group, depending on depth: re-host, re-platform, refactor or retire. Source architecture and target architecture options with pros and cons. Governance concept. Migration approach and wave plan. Risk register. Effort and cost estimate. PoC or pilot definition. |
| Client inputs | Quick clarification calls (15–30 minutes) when we hit unknowns. Answers to open questions within 2–3 working days. |
| Output | First draft of the assessment report. |
Phase 4 — Review and refine (weeks 4–5)
| Goal | Agree on the content with the client before finalising it. |
|---|---|
| Aliz activities | Walk through the draft (technical and business sessions). Collect feedback. Fill in the details. Finalise the architecture decisions (ADRs). |
| Client inputs | Key stakeholders review the draft and give feedback, ideally in one consolidated round. Decisions on the open architecture options. |
| Output | Final draft agreed in content. |
Phase 5 — Readout and handover (weeks 5–6)
| Goal | Present the results and hand them over so the client can act on them. |
|---|---|
| Aliz activities | Final presentation to the sponsor and stakeholders (interactive workshop). Handover of all documents and the completed workbook. A short support window after handover for questions. |
| Output | Final assessment report, roadmap, PoC or pilot plan with estimate, and the readout deck. |
3.3 Week-by-week view (5-week example)
| Activity | Prep | W1 | W2 | W3 | W4 | W5 |
|---|---|---|---|---|---|---|
| Scope, NDA, access requests, survey sent | ■ | |||||
| Kick-off | ■ | |||||
| Interviews | ■ | ■ | ▫ | |||
| Survey completion (client) | ▫ | ■ | ■ | |||
| Hands-on checks and automated extraction | ■ | ■ | ■ | |||
| Current-state analysis | ■ | ■ | ||||
| Target architecture and roadmap | ■ | ■ | ||||
| Draft review with client | ■ | |||||
| Finalise and readout | ▫ | ■ |
■ main activity · ▫ tail or partial
4. What we assess: workstreams and checklist
| # | Workstream | Key questions we answer |
|---|---|---|
| 1 | Business context and objectives | Why now? Which outcomes (cost, agility, freshness, new use cases, data-centre exit)? How do we measure success (SLA parity, cutover window, data-integrity KPIs)? |
| 2 | Source systems | Which systems, which technology and version, what volume and daily increment, what growth, what PII, how to connect (auth, network), how often the model changes, which environments exist? |
| 3 | Current DWH / data platform (migration) | Technology and version, number of objects, data volume, history horizon, data model documentation, business glossary, known limitations |
| 4 | Pipelines and orchestration | Tools and versions, number of jobs, languages, batch vs stream, schedules, hosting, licence terms, number of developers, documentation, what to keep vs replace, complexity, design patterns, to what extent can the migration be automated |
| 5 | Consumers and BI | BI tools and versions, number of reports and users (editors and viewers), external users, freshness needs, exports and APIs to third parties, ad-hoc analysis habits, currently unfulfilled needs |
| 6 | Cloud foundations | Existing GCP footprint, org structure and IAM, identity (e.g. AD synced with Cloud Identity), network connectivity and bandwidth, VCS and CI/CD, coding standards |
| 7 | Security and compliance | PII, PCI and other sensitive data, GDPR, consent management, encryption and key management, access model down to column and row level, audit, data residency |
| 8 | Operations | SLAs and SLOs, monitoring and alerting, logging, incident handling, backup, DR (RPO/RTO), release and change management, maintenance windows |
| 9 | Governance and data quality | Ownership, catalogue and metadata, lineage, data-quality checks, retention and archiving, data contracts between producers and consumers |
| 10 | Organisation and skills | Team setup, bottlenecks, skills gap, who will run the platform, need for enablement or a Centre of Excellence |
| 11 | Cost and TCO | Current licence, infrastructure and people costs vs the projected GCP run cost; migration cost; possible Google funding programmes (to be checked per deal) |
4.1 Migration-type specific checks
| Scenario | Extra focus |
|---|---|
| On-prem → GCP | Network (Interconnect vs VPN, bandwidth for the historical load and for daily increments), firewall and proxy constraints, on-prem staging or gateway layer, pseudonymisation before upload, cost of licence renewals during the parallel run |
| Other cloud (AWS/Azure/Snowflake…) → GCP | Egress costs, IAM mapping, replacements for proprietary services, contract end dates, multi-cloud interim state |
| GCP → GCP (carve-out or re-organisation) | Resource hierarchy, billing account moves, shared VPC and cross-project dependencies, service accounts and keys, project moves vs step-by-step rebuild |
4.2 Tooling we use (discovery and migration planning)
| Tool | What it gives us | Notes |
|---|---|---|
BigQuery migration assessment + dwh-migration-dumper | Metadata and query-log analysis of the legacy DWH: object inventory, query complexity, usage patterns, cost and optimisation insights, output as a report and as queryable tables | GA for Teradata, Snowflake, Amazon Redshift and Hive. Preview for Oracle/Exadata, Databricks, Cloudera/Hadoop and Redshift Serverless. Google recommends at least two weeks of query logs. |
| BigQuery SQL translation (batch or interactive) | A dry run of the legacy SQL and stored procedures, showing how much translates automatically and where manual work is needed | Feeds directly into the migration effort estimate |
| Google Cloud Migration Center | Infrastructure discovery and TCO for server- and VM-based workloads | Useful when the DWH or ETL runs on on-prem servers |
| Project migration between organisations (Resource Manager, also known as Project Mover) | For GCP → GCP carve-outs and re-organisations: moves whole projects to another organisation as a metadata operation. Project IDs, resources and direct IAM bindings stay, and workloads keep running. During the assessment we check each project against what does not carry over (inherited IAM, org policies, org-level custom roles, quota overrides, discounts and support), so we can decide which projects to move and which to rebuild. | Only relevant for GCP → GCP scenarios. Docs |
| Data Validation Tool (open source) | Planned for later reconciliation between source and target | We define the validation approach during the assessment |
| Native queries (INFORMATION_SCHEMA, system catalogues, orchestrator metadata, BI admin APIs) | Inventories, sizes, job lists, report usage | Works for any source, including ones the Google tools don't support |
5. What we need from the client
This is the most important section for setting expectations. An assessment is a joint effort. Its quality depends on the client's people being available and on access arriving on time.
5.1 People
| Role (client side) | Why we need them | When | Estimated time commitment |
|---|---|---|---|
| Executive sponsor | Owns the goals and success criteria, unblocks decisions and access | Kick-off, draft review, readout | ~4–6 h in total |
| Project coordinator / single point of contact | Organises interviews, chases inputs and access, owns the survey | Throughout | ~2–4 h per week |
| Business owners / key report users (1–3 domains) | Priorities, pain points, KPIs, use cases | Weeks 1–2, draft review | 1–2 × 90-min sessions each |
| DWH / data platform lead | Architecture, data model, known issues. Our main technical counterpart | Throughout | ~4–6 h per week in weeks 1–3 |
| Data engineers / ETL developers | Pipelines, jobs, schedules, hidden logic | Weeks 1–3 | 2–3 sessions plus ad-hoc questions |
| Source system owners (ERP, POS, CRM, e-com…) | Interfaces, extract options, constraints, change plans | Weeks 1–2 | 1 × 60-min session per major system |
| BI / reporting lead | Report inventory, tools, users, freshness | Weeks 1–2 | 1–2 sessions |
| Infrastructure / network / cloud team | Hosting, connectivity, existing GCP setup, identity | Week 1–2 | 1 × 90-min session |
| IT security / CISO and DPO | Security policies, PII, GDPR, access model, data residency | Early in the assessment, as availability allows | 1 × 60–90-min session |
| Operations / support | SLAs, monitoring, DR, incidents | Week 2 | 1 × 60-min session |
| Finance / procurement (optional) | Current licence and infrastructure costs for the TCO | Weeks 2–3 | Written input |
| Third-party vendors / operators (if relevant) | Systems run by external parties | As needed | Via the coordinator |
Indicative total client effort: about 40–80 person-hours spread across roles, most of it in weeks 1–3.
5.2 Documents and information
- High-level architecture diagram of the current data platform (even an outdated one helps)
- Motivation and goals of the initiative, plus any strategy papers or business cases
- Survey workbook filled in (section 9), at least the Datasource, Pipelines, Consumer and BI catalogues
- Data model, ERDs and data dictionary for the DWH, business glossary (if they exist)
- Pipeline and ETL documentation, job list, schedule
- Report inventory and user counts from the BI admin console
- Interface specifications and API documentation for the main source systems
- Security, IT and cloud policies (naming, IAM, encryption, data classification)
- SLA/SLO definitions, DR policy (RPO/RTO)
- Current cost information: licences, infrastructure, support contracts and renewal dates
- Known issues and incident history for the data platform (if available)
- Plans for adjacent projects (ERP replacement, new POS, group-level initiatives), so our roadmap does not duplicate or conflict with them
5.3 Access (read-only is enough)
| Access | Purpose |
|---|---|
Read-only access to DWH metadata and system catalogues, or a client-side run of dwh-migration-dumper | Inventory and query-log analysis |
| Query logs for ≥ 2 weeks, ideally covering month-end | Workload and usage patterns |
| Read access to the ETL/ELT code repositories and the orchestrator UI (Airflow, Talend, SSIS, Informatica, cron…) | Pipeline audit and dependency mapping |
| BI tool admin or viewer access, or usage exports | Report usage analysis |
| Sample or read access to key source tables (masked if needed) | Profiling and data-quality checks |
| GCP organisation viewer (if a GCP footprint exists), billing export | Foundations review and cost baseline |
| Workspace or collaboration access (shared drive, chat channel) | Day-to-day collaboration |
If direct access is not possible for security reasons, we can provide scripts and queries for the client team to run, then analyse the output. This takes longer, so plan an extra week.
5.4 Ways of working
- Interview slots booked in the first two weeks, confirmed before kick-off.
- Answers to open questions within 2–3 working days.
- One consolidated round of feedback on the draft.
- Decisions on architecture options made by named decision-makers, not by committee after the readout.
6. What the client gets (deliverables)
| Deliverable | Contents |
|---|---|
| Assessment report | See the structure below |
| Completed survey workbook | Catalogue of sources, pipelines, consumers and BI: the inventory the client keeps and maintains |
| Target architecture | High-level GCP architecture, with alternatives and pros and cons where relevant, plus ADRs for key decisions |
| Roadmap | 6–12-month phased plan across tracks (assessment follow-ups, data engineering framework, data marts or domains, BI, data science) |
| PoC or pilot definition | Scope, success criteria, detailed task list, effort and cost estimate. This is the first milestone of the roadmap |
| Readout deck | Executive summary for the sponsor and management |
The granularity of the inventory, dependency analysis, workload decisions and estimate follows the agreed depth (section 1.4).
Assessment report structure (standard template to be finalised):
- Executive summary: objectives, key findings, recommendation
- Engagement process and participants
- Current state: sources, DWH, pipelines, consumers and BI, infrastructure, security, operations
- Findings: pain points, gaps, risks, tech debt, quick wins
- Dependency analysis
- Target architecture: design considerations, options with pros and cons, recommended option
- Governance concept: ownership, catalogue, quality, PII, access, retention, DR
- Migration or build strategy: decisions per workload or system group (re-host, re-platform, refactor, retire), wave plan, cutover and parallel-run approach, validation approach
- Organisation and skills recommendations
- TCO and cost estimate
- Roadmap and PoC or pilot plan
- Risk register and open questions
- Appendices: inventories, ADRs, interview log
Reference: the Auchan Hungary assessment report followed most of this structure. It covered source systems, the existing pipelines and toolkit, a domain-distributed data-mart concept with organisational and technology impact, three ingestion architecture alternatives with pros and cons, a big-picture architecture, a report structure, a 12-month multi-track roadmap and the PoC contents.
7. Risks that can derail an assessment, and how we handle them
| Risk | What it looks like | How we mitigate |
|---|---|---|
| Access delays | Week 2 and still no read access | Start access requests in phase 0. Offer scripts the client can run. Flag it in weekly status. |
| Stakeholder availability | Key people are double-booked; interviews slip | Book all interviews before kick-off. The sponsor makes the time commitment clear. |
| "Reality gap" | Documentation or statements differ from what the systems show | Hands-on checks and log analysis. We present evidence neutrally and without blame. |
| Hidden dependencies and black boxes | Undocumented jobs, Excel macros, exports to partners, logic nobody owns | Log-based usage and lineage analysis. We call black boxes out explicitly and plan reverse engineering. |
| Changing requirements mid-assessment | Scope creeps (a new domain, ML use cases) | Scope boundaries agreed on at kick-off. New items go to a "next assessment" backlog or a change request. |
| Missing program management | Several projects run in parallel on the client side (a new ERP, a group-level data programme, infrastructure or network changes), and nobody coordinates them. Another project's result or task becomes our dependency or blocker, e.g. network connectivity, a source system replacement, or access provisioning. | Map parallel projects and their owners in phase 1. Log cross-project dependencies in the risk register, each with an owner and a due date. Ask the sponsor to name a client-side program owner, or to run a regular cross-project sync. Align the roadmap with the other projects' timelines. |
| Unclear business priorities | Everything is priority 1 | A prioritisation workshop scoring value against feasibility. The sponsor decides. |
| Underestimated complexity | We fall behind the plan, and the effort needed to reach the agreed on granularity keeps growing | Agree on the depth up front (section 1.4) and time-box each workstream. Hold a checkpoint around week 2: if complexity is above plan, put the trade-off to the sponsor (narrow the scope, sample instead of mapping in full, or extend through a change request). Prioritise tier-1 workloads, and state in the report what was sampled and what was fully assessed. |
8. Sales toolkit
8.1 Qualifying questions for the first call
These help us understand the context and size the assessment:
- What is driving this initiative now: cost, a licence renewal, a data-centre exit, performance, new use cases, or a group mandate?
- Is this mainly a migration, a green-field build, or both?
- What is the current DWH or data platform (technology and version), and roughly how big is it (TB, number of tables, number of ETL jobs)?
- How many source systems feed it, and which are the critical ones (ERP, POS, e-commerce, CRM…)?
- Which BI tools are in use, with roughly how many reports and users?
- Where does it run: on-prem, another cloud, or already partly on GCP?
- Are there hard deadlines, such as licence or contract end dates, or a data-centre exit?
- Who is the sponsor, and who would be our technical counterpart?
- Are there security or compliance constraints we should know about early (PII, data residency, strict access rules)?
- Are there parallel initiatives (ERP change, group-level data programme) we need to align with?
- What would make the assessment a success for you?
8.2 Sizing guidance (indicative, to be refined)
| Size | Typical landscape | Duration | Aliz team |
|---|---|---|---|
| S | 1 DWH, < 10 sources, < 200 ETL jobs, one BI tool, 1 business domain in focus | 3–4 weeks | Data architect + data engineer (part-time), PM or account manager |
| M | 1–2 DWH or marts, 10–30 sources, several hundred jobs, 1–2 BI tools, 2–3 domains | 5–6 weeks | Data architect + 1–2 data engineers, PM |
| L | Several platforms, multi-country or group context, > 30 sources, heavy stored-procedure logic | 6–10 weeks, or split into waves | Lead architect + architects and engineers per workstream, PM, optional security or ML specialist |
Durations assume standard depth (section 1.4). A light assessment is shorter; a deep one can take two to three times as long.
A typical Aliz assessment team: data architect (lead), data engineer(s) for hands-on checks, project manager, account manager. We add specialists as needed: security, ML, BI.
8.3 Common objections
| Objection | Suggested answer |
|---|---|
| "Why pay for an assessment? Just give us a migration quote." | Without the inventory, any fixed quote carries a large risk premium or leads to change requests. The assessment turns unknowns into facts, and the report is theirs to use with any vendor. |
| Catch 22: "We'll only pay for an assessment if you give us a convincing offer for the whole migration." (But a precise offer needs the assessment.) | Give a convincing offer without committing to exact effort and timeline: an indicative migration estimate as a range, with stated assumptions, based on the discovery call and reference projects. The assessment then firms it up. Options that make this easier to accept: run the assessment as phase 0 of the migration contract, with a go/no-go gate and re-baselining afterwards, or credit the assessment fee against the migration if they proceed. (Which options we offer is a commercial decision for each deal.) |
| "We already know our system." | Almost always true for the core. The surprises sit at the edges: unused reports, undocumented jobs, downstream exports. Log analysis finds them in days. |
| "We don't have time to support this." | The effort is bounded (section 5.1) and concentrated in 2–3 weeks. We do the heavy lifting; they provide access and answers. |
| "Security won't give you access." | Read-only access is enough, and we can supply scripts for their team to run. Sensitive data can be masked. |
| "Can't we just lift and shift?" | Sometimes that is the right call for part of the estate, and the assessment tells them which part. A blanket lift-and-shift usually moves the cost and the tech debt along with the data. |
9. Appendix: the assessment survey workbook
Our standard template, [template] Data and AI assessment survey, is sent to the client in phase 0. Tabs:
| Tab | Content | Who fills it (client) |
|---|---|---|
| Start | Purpose and instructions | — |
| Foundations | Existing GCP workloads, identity management, org and IAM, network connectivity and bandwidth, VCS, CI/CD, code and security standards, SLA, DR (RTO/RPO) | Cloud, infra and security team |
| Data survey | Architecture diagram, motivation and goals, current DWH (technology, number of tables, volume, data model, glossary, history horizon, limitations), future pipeline preferences (code vs GUI), ad-hoc analytics, governance tools (discovery, metadata, lineage, DQ), consent management | DWH lead |
| Datasource catalog | Per source: description, PII, operator, system type and version, format, location, total volume, daily increment, growth, documentation, number of objects, model change frequency, environments, authentication, network reachability, current and future integration | Source owners and data engineers |
| Current data pipelines catalog | Per tool: transformations, operating model, licence, batch or stream, pain points, version, number of jobs, sources and destinations, language, orchestration, hosting, frequency, number of developers, environments, documentation, keep or replace | Data engineers |
| Data consumer catalog | Per consumer: integration method, format, frequency, location, daily egress, documentation, environments, authentication, freshness, pain points | Data engineers and application owners |
| BI/Reporting catalog | Per BI tool: version, data sources, environments, authentication, editors and viewers, number of reports, external users, freshness, pain points (current and future) | BI lead |
| ML Survey (optional) | Use case, expected value, success criteria, stakeholders, data types, labels, data size, MLOps and serving needs, security constraints | Data science lead |
| Customer Lifecycle (optional) | Acquisition, customer journey, channels, KPIs, omnichannel data, consent | Marketing and CRM |
| Codetables | Value lists for the catalogues | — |
Tip: ask the client to fill in what they can before kick-off, even partially. Gaps are fine; we complete them together in interviews.
10. Next steps to turn this into a standard (internal)
- Finalise a standard assessment report template, using section 6 and the Auchan report as a base.
- Refresh the survey workbook (v1 is from 2021): add lakehouse and streaming topics, data contracts, a GenAI/AI-readiness section, and cost inputs for the TCO.
- Write hands-on check playbooks: dumper runs, standard inventory queries per source type, Airflow version check, BI usage extraction.
- Build a standard kick-off deck and readout deck (the 2020 Auchan kick-off can serve as a base).
- Add anonymised reference cases with measurable outcomes for the pitch deck.
- Validate the sizing table and client-effort estimates against the last 3–5 assessments.
- Calibrate the depth levels (section 1.4): durations, confidence ranges and what each level delivers, using recent engagements (e.g. Fenaco, Müller).
- Agree on which commercial options for the catch-22 objection (section 8.3) we are willing to offer as standard.
- Check the current partner status and Google funding programmes (assessment or migration incentives) before using them in client material.
Sources used for this draft
- GCP Data Migration Assessment Project Guide (internal draft)
- [template] Data and AI assessment survey (internal workbook, v1)
- Resident Data Specialist Discovery Questionnaire (generic discovery procedure)
- Auchan–Aliz Data assessment kick-off deck (2020): team, phases, timeline, deliverables
- Auchan – Data Assessment report: reference assessment output
- Google Cloud docs: BigQuery migration assessment, Introduction to BigQuery migration