Senior systems analysts do more than write requirements: they shape how a new system fits into everything the business already runs. This mid-level course follows one running example, Harbor Outfitters, a mid-sized outdoor-gear retailer replacing a home-grown customer database with a CRM connected to its ERP and web shop. You will map an enterprise systems landscape, draw context and data-flow diagrams, and score build-versus-buy options with a weighted matrix. In the integration module you read an API specification and test real calls, write a source-to-target data mapping in SQL, and plan a data migration with reconciliation queries that prove nothing was lost. The delivery module covers user acceptance test scripts, training and a go-live cutover plan, and compares the analyst certifications from IIBA (ECBA, CCBA, CBAP) and PMI. Activities are paper or free-tool tasks and SQLite exercises that run in your browser. It builds on Business & Systems Analysis, SQL for Analysis and Networking Fundamentals.

Design how business systems fit together: map the landscape, draw data flows, choose build or buy, specify integrations and data migrations, and deliver with UAT and change management.

Solution Design & Integration

## Why it matters

No new system arrives in an empty room. A new CRM must receive customers from the web shop, send orders to the ERP, and feed the finance reports, while the old systems keep running. Most of the risk in a project sits in those connections. A systems analyst who can draw the whole landscape on one page spots missing interfaces, duplicate data and hidden dependencies before they become late surprises.

## The core idea: systems of record

A typical organisation runs a handful of major systems, each the **system of record** (the authoritative source) for certain data:

| System | What it does | Usually the system of record for |
|---|---|---|
| **ERP** (Enterprise Resource Planning: SAP, Oracle, Microsoft Dynamics 365, NetSuite) | Finance, purchasing, inventory, manufacturing, order fulfilment | Products, prices, stock, invoices, the general ledger |
| **CRM** (Customer Relationship Management: Salesforce, Dynamics 365 Sales, HubSpot) | Sales pipeline, marketing, customer service | Customers, contacts, leads, cases |
| **HRIS** (HR Information System: Workday, BambooHR) | People, payroll, absence | Employees, org structure |
| **E-commerce platform** | Online catalogue, basket, checkout | Web sessions, carts (orders pass to ERP) |
| **Data warehouse / lakehouse** | Reporting and analytics | Nothing; it is a copy for analysis |
| **Identity provider** (Microsoft Entra ID, Okta) | Sign-in and access for staff | User accounts and groups |

The rule that keeps a landscape sane: **each data entity has exactly one system of record.** Other systems may hold copies, but changes flow from the master. When two systems both think they own the customer's address, you get conflicts that no integration can fix.

## Integration styles

How systems exchange data, from oldest to newest:

- **File transfer:** nightly CSV files over SFTP. Simple and still common; data is up to a day old.
- **Shared database:** two apps reading the same tables. Fast to build, painful to change; avoid for new work.
- **Point-to-point APIs:** system A calls system B's API directly. Fine for a few connections, but with many systems the lines multiply into a "spaghetti" diagram.
- **Middleware / iPaaS** (integration platform as a service, such as MuleSoft, Boomi, Azure Logic Apps): a central hub that transforms and routes messages.
- **Event-driven:** systems publish events ("order placed") to a message broker, and any interested system subscribes.

The analyst does not usually pick the technology alone, but should record for every interface: source, target, data, trigger, frequency, direction and owner.

## Worked example: Harbor Outfitters

Harbor Outfitters sells outdoor gear in 12 stores and online. Today it runs:

- An ERP (NetSuite) for stock, purchasing and finance.
- A Shopify web shop.
- A 15-year-old in-house **customer database** (Microsoft Access) used by store staff for loyalty points.
- Point-of-sale (POS) tills in each store.
- Spreadsheets for the marketing email list.

The project: replace the customer database and the spreadsheets with a CRM. The analyst's first landscape map, as an interface list:

```text
ID   Source      Target      Data                   Trigger / frequency
I-01 Web shop    ERP         Orders                 Each order (API)
I-02 POS         ERP         Store sales            Nightly file
I-03 POS         Cust DB     Loyalty points         Each sale (shared DB)
I-04 Web shop    Cust DB     New customers          Manual re-keying, weekly
I-05 Cust DB     Marketing   Email list             Monthly export to spreadsheet
I-06 ERP         Data wh.    Sales, stock           Nightly file
```

Two findings jump out. **I-04 is manual re-keying**: staff type web customers into the old database, so the CRM project must automate it. **I-03 uses a shared database**, which will break when the old database is switched off; the POS vendor must be involved early. The future-state map makes the CRM the system of record for customers and loyalty, with I-03, I-04 and I-05 replaced by APIs.

## Common mistakes

- Mapping only the systems in scope and missing the ones that feed them.
- Ignoring spreadsheets and manual steps; they are interfaces too, and often the riskiest.
- Two systems of record for the same entity.
- Forgetting non-functional details: volumes, timing, error handling and who gets called when an interface fails.

## Quick recap

- Each major system is the system of record for some data; keep exactly one master per entity.
- Interfaces range from nightly files to APIs, middleware and events; record source, target, data, trigger, frequency and owner.
- A landscape map and interface list reveal manual steps and hidden dependencies early.


Map the main systems a business runs, such as ERP and CRM, and the data that flows between them.

Enterprise systems landscape

What is Enterprise Architecture (EA) and why is it important? EA concepts explained in a simple way.

ERP vs CRM: What’s the Difference? (How to Choose)

Pick a process you know well: a library loan, a gym membership sign-up, a school's homework submission, or the Harbor Outfitters web order. Write a one-sentence description of the system boundary.

List every external entity (people, organisations, other systems) that gives data to the system or gets data from it.

Draw the context diagram: one central process, the entities around it, and a labelled arrow for each data flow. Use specific nouns on every arrow.

Draw a level-0 DFD with 3 to 6 numbered processes (verb phrases) and the data stores they need (D1, D2...).

Check every flow on the context diagram appears on the DFD (balancing), and every process has at least one input and one output.

Check for illegal flows: entity to entity, store to store, entity straight to store. Fix any you find by adding a process.

Show the diagrams to someone who knows the process and ask them to find one missing or wrong flow. Correct it.

## Why it matters

Stakeholders agree with long text documents and then discover, months later, that they understood them differently. A diagram that fits on one page is much harder to misread. Context diagrams and data-flow diagrams (DFDs) are the analyst's fastest way to agree on scope ("what is inside our system and what is outside") and on what data moves where.

## The core idea

A **context diagram** (also called a level-0 DFD in some textbooks, or a system context diagram) shows:

- **One process**: the system you are building, drawn as a single circle or rounded box.
- **External entities**: people, organisations or other systems that send data to it or receive data from it, drawn as rectangles.
- **Data flows**: labelled arrows showing what data moves, and in which direction.

It deliberately shows nothing inside the system. Its job is scope: anything not on the diagram is not part of the project.

A **data-flow diagram** opens the box. A level-0 (or level-1, depending on the textbook) DFD splits the system into its main processes and adds:

- **Processes**: numbered verbs ("1.0 Register customer"), each transforming input into output.
- **Data stores**: places data rests, such as a table or file, drawn as an open-ended rectangle labelled D1, D2...
- **Data flows**: labelled with nouns ("customer details", "points balance").

DFDs show data, not control. There are no decisions, loops or timing: that is what activity diagrams and BPMN process maps are for.

## Rules that catch mistakes

- Every process must have at least one input and one output. A process with only inputs is a **black hole**; one with only outputs is a **miracle**.
- Data cannot flow directly between two external entities, or between two data stores, or from an external entity straight into a store. A process must sit in between.
- Flows into and out of a lower-level diagram must **balance** with the level above: if the context diagram shows "order" going in, the DFD must too.
- Label every flow with a specific noun. "Data" or "info" means you have not decided what moves.

## Worked example: Harbor Outfitters loyalty

The CRM project's context diagram, written as text:

```text
External entities: Customer, Store staff (POS), Web shop, ERP, Email service

Customer   --sign-up details-->        [CRM loyalty system]
Customer   <--points statement--       [CRM loyalty system]
POS        --sale (customer id, total)--> [CRM]
POS        <--points balance--          [CRM]
Web shop   --new web customer-->        [CRM]
ERP        <--customer account details-- [CRM]
Email svc  <--marketing list, opt-ins--  [CRM]
```

The level-0 DFD opens it into four processes and two stores:

```text
1.0 Register customer    in:  sign-up details, new web customer
                         out: customer record -> D1 Customers
                              customer account details -> ERP
2.0 Award points         in:  sale (from POS), customer record (D1)
                         out: points transaction -> D2 Points ledger
3.0 Report balance       in:  points transactions (D2)
                         out: points balance -> POS, points statement -> Customer
4.0 Build mailing list   in:  customer record with consent (D1)
                         out: marketing list -> Email service
```

Check it against the rules: every process has inputs and outputs; the POS never writes straight into D2 (process 2.0 does); the flows to and from external entities match the context diagram. Drawing process 4.0 also raised a real requirement: consent must be stored on the customer record, or the mailing list breaks privacy law.

## Tools

Paper and a pencil are fine for a first draft. For sharing, use any diagramming tool: diagrams.net (draw.io, free in the browser), Lucidchart, Miro or Visio. Pick one symbol set (Gane-Sarson or Yourdon-DeMarco) and stick to it.

## Common mistakes

- Drawing control flow (if/then, loops) on a DFD.
- Unlabelled or vaguely labelled arrows.
- External entities connected directly to data stores.
- A context diagram cluttered with internal detail, which defeats its purpose.
- Not walking stakeholders through it; a diagram nobody has reviewed has not been agreed.

## Quick recap

- A context diagram shows one system, its external entities and the data flows between them: it defines scope.
- A DFD breaks the system into numbered processes and data stores; it shows data, not control.
- Check for black holes, miracles, illegal direct flows and unbalanced levels.

## Try it

In the Do tab you draw both diagrams for a process you know.


Draw a context diagram and a level-0 data-flow diagram for a business process.

Context and data-flow diagrams

How to Use a System Context Diagram in Business Analysis (with example)

Data Flow Diagrams - What is DFD? Data Flow Diagram Symbols and More

Pick a decision: the Harbor Outfitters CRM, a note-taking app for your team, a learning platform for a club, or a tool at your workplace. Write a one-paragraph problem statement.

Write 2 or 3 must-have gates (yes/no requirements an option must meet).

Choose 4 to 6 weighted criteria and give them weights that add up to 100%. Write one sentence on why the top-weighted criterion matters most.

Pick at least three options, including one build or do-nothing option. For each, find evidence from official product pages, free trials or documentation (not reviews alone).

Score each option 1 to 5 per criterion and write the evidence for each score in a notes column. Apply the must-have gates first.

Calculate the weighted totals with a formula (for example `=SUMPRODUCT(weights, scores)`).

Sensitivity test: move 5 to 10 points of weight between your top two criteria. Does the winner change? Write down what that tells you.

Write a three-sentence recommendation with one key risk and how you would reduce it.

## Why it matters

"Should we build it ourselves or buy a product?" is one of the most expensive decisions a project makes, and it is often made on gut feeling or on the best sales demo. Analysts bring structure: clear requirements, a fair comparison and a recorded rationale that someone can revisit in two years when the decision is questioned.

## The options are wider than two

- **Buy (SaaS or packaged software):** use the product largely as it comes. Fast to start, the vendor handles upgrades, but you adapt your process to the product.
- **Configure:** buy a platform and set it up with settings, workflows and fields (most CRM and ERP projects).
- **Customise / extend:** add code on top of a product. Powerful, but every customisation can break at upgrade time.
- **Build:** write your own. Full control and fit, but you own every bug, upgrade and security patch forever.
- **Hybrid:** buy the commodity parts and build the parts that differentiate you.

A useful rule of thumb: **buy what is commodity, build what is differentiating.** Payroll, email and accounting work the same way for nearly everyone; buy them. A unique pricing engine that wins you customers may be worth building.

## Total cost of ownership

Compare costs over several years, not just the first invoice:

```text
Buy:    licences/subscriptions x users x years
        + implementation partner + data migration + integrations
        + training + internal admin time
Build:  development team x duration
        + hosting + security and compliance work
        + ongoing maintenance (often 15-25% of build cost per year)
        + the opportunity cost of what that team is not building
```

## The weighted scoring matrix

1. **Agree the criteria before you see demos**, from the requirements: functional fit, integration (APIs available), security and compliance, total cost, vendor viability, usability, time to deliver.
2. **Weight them** so they sum to 100%. Stakeholders agree the weights; this is where priorities become explicit.
3. **Score each option** 1 to 5 against each criterion, using evidence: scripted demos (give vendors your scenarios), reference calls, a trial or proof of concept.
4. **Multiply and sum.** The highest total is the recommendation, unless an option fails a **must-have** gate, which disqualifies it whatever its score.

## Worked example: Harbor Outfitters CRM

Must-have gates: stores customer consent; has a documented REST API; can import 180,000 legacy customers.

| Criterion | Weight | Vendor A (SaaS CRM) | Vendor B (CRM suite) | Build in-house |
|---|---|---|---|---|
| Functional fit (loyalty, segments) | 30% | 4 | 5 | 5 |
| Integration with NetSuite and Shopify | 20% | 5 | 3 | 3 |
| 5-year total cost | 20% | 4 | 2 | 2 |
| Time to go live | 15% | 4 | 3 | 1 |
| Usability for store staff | 15% | 4 | 3 | 4 |

Weighted totals (score x weight, summed):

```text
Vendor A: 4(.30)+5(.20)+4(.20)+4(.15)+4(.15) = 1.2+1.0+0.8+0.6+0.6 = 4.20
Vendor B: 5(.30)+3(.20)+2(.20)+3(.15)+3(.15) = 1.5+0.6+0.4+0.45+0.45 = 3.40
Build:    5(.30)+3(.20)+2(.20)+1(.15)+4(.15) = 1.5+0.6+0.4+0.15+0.6 = 3.25
```

Vendor A wins clearly, even though Vendor B has the best features. The recommendation document records the scores, the evidence behind each, the risks (Vendor A's loyalty module is newer) and the mitigations (a 30-day proof of concept on loyalty before signing).

## Beyond the score

Also check: data ownership and export (can you leave with your data?), where data is hosted, the vendor's security certifications (such as SOC 2 or ISO 27001), contract length and exit terms, and the product roadmap. Sensitivity test the result: if changing one weight by 5 points flips the winner, the decision is close and needs more evidence.

## Common mistakes

- Choosing criteria after the demos, which bends them toward the favourite.
- Letting vendors run their own demo script instead of your scenarios.
- Comparing year-one licence price against a build estimate without maintenance.
- Heavy customisation of a bought product, which gives you the costs of both options.
- No recorded rationale.

## Quick recap

- Options range from buy to configure, customise, build and hybrid; buy commodity, build differentiators.
- Compare total cost of ownership over several years.
- Use must-have gates plus a weighted matrix agreed before demos, scored with evidence.

## Try it

The Do tab asks you to build a weighted matrix for a real decision.


Compare building, buying and configuring a product, and score vendor options with a weighted matrix.

Build vs buy

Buy Software or Build It? The 4-Step Framework That Prevents Costly Mistakes

Map the systems a business runs, draw how data flows between them and decide whether to build or buy.

Systems Architecture

Open jsonplaceholder.typicode.com and read the list of resources and routes it supports.

Run `curl -i https://jsonplaceholder.typicode.com/users/1`. Note the status code, the `Content-Type` header and three fields from the body.

Run `curl -i "https://jsonplaceholder.typicode.com/posts?userId=1"`. Count how many records come back and note how the query parameter filtered them.

Run a call for a user that does not exist (`/users/9999`) and note the status code and body.

Send a POST to `/posts` with a JSON body (see the lesson) and note the status code and the `id` returned.

Open the Swagger Petstore demo specification (petstore3.swagger.io) and find one endpoint. Write down its method, path, required parameters, success response fields and documented error codes.

Write a three-sentence integration requirement for that endpoint, covering success, not found and time-out behaviour, as in the lesson.

## Why it matters

Most integrations today are built on APIs (application programming interfaces). An analyst who can read an API specification can answer questions that would otherwise wait days for a developer: "Does the vendor's API give us the loyalty balance?", "Can we filter orders by date?", "What happens if the customer does not exist?" You do not need to write the integration code, but you do need to specify it precisely and test that it behaves as the requirements say.

## The core idea: requests and responses

A web API (usually REST over HTTPS) works like a structured conversation. The client sends a **request**:

- **Method**: what to do. `GET` reads, `POST` creates, `PUT` or `PATCH` updates, `DELETE` removes.
- **URL**: which resource, for example `https://api.example.com/v1/customers/1042`. Parts after `?` are **query parameters**, such as `?status=active&limit=50`.
- **Headers**: metadata, such as `Authorization: Bearer <token>` and `Content-Type: application/json`.
- **Body**: the data sent with `POST`, `PUT` or `PATCH`, usually JSON.

The server returns a **response** with a **status code** and usually a JSON body:

| Code | Meaning |
|---|---|
| 200 OK, 201 Created | Success (201 after creating something) |
| 400 Bad Request | The request was malformed or failed validation |
| 401 Unauthorized / 403 Forbidden | Not authenticated / not allowed |
| 404 Not Found | The resource does not exist |
| 409 Conflict | It clashes with the current state, such as a duplicate |
| 429 Too Many Requests | Rate limit hit; slow down and retry later |
| 500-599 | Server-side error; often worth retrying |

## Reading a specification

Most modern APIs publish an **OpenAPI** (formerly Swagger) specification, often rendered as interactive documentation. A fragment:

```yaml
paths:
  /customers/{id}/points:
    get:
      summary: Get a customer's loyalty balance
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string }
      responses:
        "200":
          description: Balance found
          content:
            application/json:
              schema:
                type: object
                properties:
                  customerId: { type: string }
                  balance:    { type: integer }
                  asOf:       { type: string, format: date-time }
        "404":
          description: Customer not found
```

From this an analyst can write: "POS calls `GET /customers/{id}/points` at checkout. On 200, show `balance`. On 404, show 'No loyalty account' and offer sign-up. On any 5xx or no reply in 2 seconds, continue the sale without points and log the failure." That sentence is an integration requirement a developer can build and a tester can check.

Things to look for in any spec: authentication method, rate limits, pagination (how to get page 2 of results), date and time formats and time zones, required versus optional fields, error formats, and versioning (what happens when v2 arrives).

## Worked example: testing calls yourself

You can test a public practice API with `curl` in a terminal, or with a graphical client such as Postman, Insomnia or Bruno. JSONPlaceholder (`jsonplaceholder.typicode.com`) is a free fake API made for practice:

```bash
curl -i https://jsonplaceholder.typicode.com/users/1
curl -i "https://jsonplaceholder.typicode.com/posts?userId=1"
curl -i https://jsonplaceholder.typicode.com/users/9999
curl -i -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title": "Test", "body": "Hello", "userId": 1}'
```

The `-i` flag shows the status line and headers. The first call returns 200 with one user; the second filters with a query parameter; the third returns 404; the fourth returns 201 with the new record (the fake API does not really save it). Writing down what you sent and what came back is the start of an interface test plan.

## Security notes

Never paste real production credentials or customer data into an online tool, a shared Postman workspace or a chat. Use test environments ("sandbox" accounts) and test data. API keys belong in the tool's secret storage or environment variables, not in saved requests you share.

## Common mistakes

- Specifying only the happy path; every interface needs rules for 4xx, 5xx and time-outs.
- Ignoring pagination and assuming the first page is all the data.
- Time zones: `2026-03-16T23:30:00Z` is already the 17th in many places.
- Assuming field meanings from names; confirm with the spec and sample data.

## Quick recap

- A request has a method, URL, headers and optional body; the response has a status code and usually JSON.
- OpenAPI specs tell you endpoints, parameters, fields and errors; turn them into precise integration requirements.
- Test with curl or Postman against sandboxes, and never with real credentials or customer data in shared tools.

## Try it

In the Do tab you read a real spec and test calls against a free practice API.


Read an API specification, understand requests and responses, and test a call yourself.

APIs for analysts

Introduction to APIs for Business Analysts

Postman Beginner Tutorial 2026 | Install Postman, Workspace, Collection & First API Request + QUIZ

## Why it matters

Every integration and every migration moves data from a **source** structure to a **target** structure, and the two never match exactly. The old system stores "Rivera, Ana" in one field; the new one wants first and last name. The old system uses status code `A`; the new one wants `active`. A **source-to-target mapping** (STTM) is the document that says, field by field, how one becomes the other. Developers build from it, testers test against it, and auditors read it later. Getting it wrong means wrong data in the new system on day one.

## The core idea: one row per target field

A mapping is usually a spreadsheet with one row per **target** field:

| Target field | Source field(s) | Transformation rule | Default / null handling | Notes |
|---|---|---|---|---|
| `external_id` | `cust_no` | prefix with `HO-` | required | used to trace back to legacy |
| `first_name` | `full_name` | text after the comma, trimmed | blank if no comma | |
| `last_name` | `full_name` | text before the comma, trimmed | whole value if no comma | |
| `state_code` | `state_name` | look up in state table, case-insensitive | `UNKNOWN`, flagged for review | |
| `status` | `status_code` | A->active, I->inactive | anything else -> review | `X` seen in data profiling |
| `joined_on` | `joined` | MM/DD/YYYY -> YYYY-MM-DD | required | |

Mapping types you will meet:

- **Direct (1:1):** copy as is, perhaps renaming.
- **Transformation:** reformat, convert units, split or concatenate.
- **Lookup / code mapping:** translate codes via a reference table.
- **Derived:** calculate from several fields.
- **Default / constant:** fill a target field the source does not have.
- **Not migrated:** record source fields you deliberately drop, and why.

## Profile the data first

Never write rules from field names alone. **Data profiling** means querying the source to see what is really there:

```sql
SELECT status_code, COUNT(*) FROM legacy_customers GROUP BY status_code;
SELECT DISTINCT state_name FROM legacy_customers ORDER BY state_name;
SELECT COUNT(*) FROM legacy_customers WHERE full_name NOT LIKE '%,%';
```

At Harbor Outfitters this revealed a status code `X` that nobody remembered (it turned out to mean "closed by fraud team") and state names typed in lower case. Both became explicit rules in the mapping rather than surprises in testing.

## Worked example: the mapping as a query

Writing the mapping as a SQL `SELECT` is a quick way to test it, because you can run it against a copy of the source and look at the output. A few rules from the table:

```sql
SELECT
  'HO-' || cust_no AS external_id,
  CASE status_code
    WHEN 'A' THEN 'active'
    WHEN 'I' THEN 'inactive'
    ELSE 'review'
  END AS status
FROM legacy_customers;
```

Text functions do the splitting and reformatting. In SQLite, `INSTR(full_name, ',')` gives the position of the comma, `SUBSTR(text, start, length)` cuts out part of a string, `TRIM` removes spaces, and `||` concatenates. Lookups use a `LEFT JOIN` so that unmatched source rows are kept, with `COALESCE(code, 'UNKNOWN')` supplying the default. An inner join would silently drop customers whose state is missing from the lookup table, which is one of the most common mapping bugs.

## Rules for good mappings

- Write the rule so two people would implement it identically. "Clean up the name" is not a rule.
- Say what happens for nulls, blanks, unknown codes and values too long for the target field.
- Keep a **traceability key** (here `external_id`) so every target record can be traced to its source.
- Version the mapping and get the data owner to sign it off; it is a requirement, not a developer note.

## Common mistakes

- Inner joins on lookups, losing records.
- Assuming one date format when the source mixes several.
- Ignoring character sets and accents (Ana vs Aña) and field lengths.
- No rule for duplicates: two legacy rows for the same person need a de-duplication rule agreed with the business.

## Quick recap

- An STTM lists each target field with its source, transformation, default and null handling.
- Profile real source data before writing rules.
- Test the mapping as a query; use LEFT JOIN plus defaults for lookups and keep a traceability key.

## Try it

In the Do tab you implement the Harbor Outfitters mapping as one SQLite query.


Write a source-to-target mapping with transformation rules and test it in SQL.

Data mapping

Creating a Data Map - A Vital Step to Data Migration & System Integration

Data Mapping Explained Practically for Business Analysts

## Why it matters

Data migration is the part of a system replacement most likely to delay go-live. The new system can be perfectly configured, but if customers' loyalty points are wrong on Monday morning, store staff will lose trust in it within an hour. A good migration is planned like a small project of its own, rehearsed several times, and proven correct with numbers rather than with "it looked fine".

## The core idea: extract, transform, load, reconcile

1. **Extract** data from the source systems into a staging area, ideally a read-only snapshot.
2. **Transform** it with the rules from the source-to-target mapping: reformat, look up codes, de-duplicate, apply defaults.
3. **Load** it into the target, in dependency order (customers before orders, orders before order lines), using the target's import tools or APIs.
4. **Reconcile:** prove the target matches the source after transformation, and explain every difference.

## The migration plan

A migration plan answers:

- **Scope:** which entities and how much history ("all customers; orders from the last 3 years; older orders archived as read-only files").
- **Data quality and cleansing:** what is fixed in the source before migration, what is fixed by rules, and who approves.
- **Approach:** **big bang** (everything moves in one cutover window) or **phased / trickle** (by region, by entity, or with both systems running in parallel for a while). Big bang is simpler; phased reduces risk but needs temporary interfaces.
- **Rehearsals:** at least two or three full trial migrations into a test environment, timed, with the same scripts as the real one.
- **Reconciliation checks** and sign-off criteria.
- **Fallback:** what happens if the migration fails during cutover, and the latest time you can decide to roll back.

## Reconciliation: proving it worked

Reconciliation works at three levels, from cheapest to most thorough:

```text
1. Counts         source rows in scope vs target rows, per entity
2. Totals         sum of money and points, per entity and per period
3. Record level   every key matched, and key fields compared
```

Counts and totals are quick and catch big failures. Record-level checks find the specific records to fix. A reconciliation report looks like this:

```text
Entity      Source  Target  Diff  Explained
Customers   180,412 180,377   35  35 duplicates merged (list attached)
Orders      612,950 612,948    2  2 orders failed validation (ticket MIG-41)
Points sum  9.81M   9.81M      0  -
```

Every difference must be **explained** in writing, not just small. "Two orders missing" is a defect until someone proves why.

## Worked example: finding exceptions in SQL

With source and target tables side by side (or extracted to a staging database), set-based queries find every exception:

```sql
-- In source but not in target
SELECT s.order_id
FROM source_orders AS s
LEFT JOIN target_orders AS t ON t.order_id = s.order_id
WHERE t.order_id IS NULL;
```

The same pattern, with the tables swapped, finds records that appeared in the target without a source (for example test data left behind). Comparing key fields where both sides exist finds transformation errors, such as an amount that lost a digit. Storing money as whole cents avoids rounding noise in these comparisons.

## Cutover timing

Measure each rehearsal. If extract, transform, load and reconciliation take 14 hours, a weekend window works; if they take 50 hours, you need a different approach (phased, or migrating history in advance and only the latest changes at cutover, often called a **delta** load).

## Common mistakes

- Treating migration as a one-off script written in the last month.
- No rehearsals, so the first real run is the cutover.
- Reconciling counts only; a wrong amount passes a count check.
- Migrating everything "just in case", including decades of history nobody uses.
- Unclear ownership: the business, not IT, must sign off that the data is right.

## Quick recap

- Extract, transform with the mapping, load in dependency order, then reconcile.
- Plan scope, cleansing, approach (big bang or phased), rehearsals and fallback.
- Reconcile counts, totals and records, and explain every difference.

## Try it

In the Do tab you write a reconciliation query that lists every exception from a trial migration.


Plan a data migration with trial runs, reconciliation checks and a fallback.

Data migration

Data Migration Examples

How to do Data Reconciliation | Match Source vs Target Data

Read API specifications, write source-to-target data mappings and plan a data migration that can be reconciled.

Integration

Pick the system: the Harbor Outfitters CRM loyalty feature, or a system you use at work or school. Write 3 requirements or user stories it must meet.

Write the plan outline: scope (in and out), 3 entry criteria, testers by role, defect severity levels (1 to 4 with one-line definitions) and 3 exit criteria.

Write a happy-path UAT script for the most important requirement with ID, requirement reference, preconditions with specific test data, numbered steps and an expected result for each step.

Write a negative script for the same requirement (invalid input, missing record or permission denied).

Write a failure or edge script (an interface is down, a name with an apostrophe or accent, a refund reversing an earlier action).

Ask someone who has never seen the system to read one script. Mark every place they were unsure what to do or what to expect, and rewrite those steps.

Add a results section to each script: actual result, pass/fail, defect ID, tester and date.

## Why it matters

A system can pass every technical test and still fail on its first morning, because it does not fit how people actually work. **User acceptance testing (UAT)** is where the business confirms that the system meets its needs, using realistic scenarios, before it goes live. The analyst usually plans UAT, writes or reviews the scripts and runs the triage meetings, because the analyst knows the requirements best.

## Where UAT sits

```text
Unit tests          developers test small pieces of code
Integration tests   interfaces between systems work (APIs, files)
System tests        the whole system against the specification (QA team)
UAT                 business users confirm it supports their work
```

UAT is not a hunt for every bug; earlier test levels do that. It answers one question: **can we run the business on this?** It needs a stable test environment, realistic (but anonymised) data, and real users from each affected group.

## The UAT plan

A short plan covers:

- **Scope:** which processes and requirements are tested, and which are out of scope.
- **Entry criteria:** what must be true before UAT starts (for example: system test passed, no open critical defects, test data loaded, users trained).
- **Testers and schedule:** named people from each group (store staff, customer service, marketing, finance) with time released from their normal work.
- **Defect process:** how to log a defect, severity levels, and who decides what is fixed before go-live.
- **Exit criteria:** what "accepted" means (for example: all critical scenarios passed, no open severity 1 or 2 defects, workarounds agreed for the rest) and who signs.

## Writing UAT scripts

Each script tests one business scenario, traced back to a requirement or user story, in steps a non-technical user can follow:

```text
ID:            UAT-LOY-03
Requirement:   US-12 "As a store associate I can look up a customer's points at checkout"
Preconditions: Test customer Ana Rivera (HO-1001) exists with 1,250 points.
               Tester is logged into the POS test till as a store associate.

Step  Action                                       Expected result
1     Scan a test item and choose Find customer    Search box appears
2     Search by phone number 555-0101              Ana Rivera is shown as the only match
3     Select Ana Rivera                            Points balance shows 1,250
4     Complete the sale of 49.99 with card         Receipt shows points earned: 49
5     Look up Ana Rivera again                     Balance shows 1,299

Actual result / Pass or Fail / Defect ID / Tester / Date
```

Good scripts have **specific data** ("1,250 points", not "some points"), one clear **expected result** per step, and cover more than the happy path. For each important requirement add negative and edge cases: a customer with no loyalty account, a refund that must remove points, the API being unavailable (the sale must still complete), a name with an apostrophe or accent.

Acceptance criteria written as Given/When/Then in the Business & Systems Analysis course convert almost directly into UAT scripts; that is one reason to write them well.

## Running UAT

- Start with a short kick-off: how to use the scripts, how to log defects.
- Hold a daily triage meeting to review new defects, agree severity and assign them.
- Track progress visibly: scripts passed, failed, blocked; defects open by severity.
- Re-test fixes with the original script, and run a small **regression** set to check nothing else broke.
- End with formal sign-off by the business owner against the exit criteria.

## Common mistakes

- Using IT staff as UAT testers; they test what was built, not how the work is done.
- Vague expected results ("works correctly").
- Production customer data in a test environment without anonymisation.
- Starting UAT on an unstable build, so testers lose confidence.
- No exit criteria, so UAT ends when the calendar says so.

## Quick recap

- UAT confirms the business can operate on the system; it comes after system testing.
- Plan scope, entry and exit criteria, testers, schedule and the defect process.
- Scripts trace to requirements, use specific data and expected results, and include negative cases.

## Try it

In the Do tab you write a UAT plan outline and three scripts.


Plan user acceptance testing and write UAT scripts that business users can run.

Test planning and UAT

Software Testing Process Guide: What is User Acceptance Testing - UAT?

How To Write Test Cases and Test Scripts For QA Testing

Pick the change: the Harbor Outfitters CRM go-live, or a system or process change you have seen at work or school.

Write a change impact table: 3 to 5 affected groups, what changes for each, and how big the impact is (low/medium/high).

For the most affected group, write one action for each ADKAR stage (awareness, desire, knowledge, ability, reinforcement).

Write a role-based training plan: who is trained, on what, how (hands-on, guide, video), when relative to go-live, and how you check they learned it.

Write a cutover runbook of at least 10 tasks with time, task, owner and dependency, including a freeze, the final migration, reconciliation, two go/no-go checkpoints and smoke tests.

Write the rollback steps and the latest time a rollback is still possible.

Define 3 adoption measures you would track in the first month and the target for each.

## Why it matters

Projects rarely fail because the software does not work. They fail because people do not use it, use it wrongly, or quietly keep their old spreadsheet. **Organisational change management** is the planned work of helping people move from the old way to the new one. **Cutover** is the planned work of moving the systems. A systems analyst often owns or contributes to both, because they understand the processes that are changing.

## The core idea: people move through stages

Many models describe how individuals accept change. Prosci's ADKAR model is widely used and easy to apply. A person needs:

1. **Awareness** of why the change is happening.
2. **Desire** to take part and support it.
3. **Knowledge** of how to work in the new way.
4. **Ability** to actually do it on the job.
5. **Reinforcement** so the change sticks.

Training only delivers Knowledge. If store staff do not understand why the old customer database is going (Awareness) or think the CRM will slow down checkout (Desire), training alone will not work. Kotter's eight-step model is another common framework, aimed more at leading change across a whole organisation.

## The change plan

- **Change impact assessment:** for each group, what changes in their daily work. For example, store associates now look customers up by phone at the till; marketing builds segments in the CRM instead of spreadsheets; customer service sees loyalty history.
- **Stakeholder and sponsor plan:** a visible senior sponsor, plus **change champions** (respected staff in each store who get early access and help colleagues).
- **Communications plan:** who hears what, when and from whom. Messages come from managers people trust, start early, explain why, and repeat.
- **Training plan:** role-based, close to go-live, hands-on in a training environment, with quick reference guides at the till.
- **Support plan:** extra help in the first weeks (floor walkers, a dedicated support channel), and measures of adoption.

## Cutover planning

The **cutover plan** (or runbook) is an hour-by-hour list of every task needed to switch from old to new:

```text
Harbor Outfitters CRM cutover, Saturday 18:00 to Sunday 20:00

T-14d  Go/no-go criteria agreed; final rehearsal passed and timed
T-2d   Communications: stores told old database becomes read-only Sat 18:00
Sat
18:00  Freeze: old customer database set to read-only          (DB admin)
18:30  Final extract of customers and points                    (Migration lead)
19:00  Transform and load into CRM                              (Migration lead)
02:00  Reconciliation report: counts and points totals          (Analyst)
03:00  Go/no-go checkpoint 1: reconciliation accepted?          (Business owner)
Sun
08:00  Switch POS and web shop integrations to CRM              (Integration lead)
10:00  Smoke tests: 10 scripted transactions in two test stores (UAT leads)
12:00  Go/no-go checkpoint 2 (point of no return)               (Sponsor)
Mon
07:00  Floor walkers in all stores; hypercare channel open      (Support lead)
```

Every task has an owner, a start time, a duration and a dependency. The plan includes **go/no-go checkpoints** with written criteria, and a **rollback plan**: the exact steps to switch back to the old system if a checkpoint fails, and the latest time a rollback is still possible. After go-live, a **hypercare** period (often two to four weeks) gives fast support and daily defect reviews before normal support takes over.

## Measuring adoption

Decide in advance how you will know the change worked: percentage of sales with a loyalty lookup, number of old spreadsheets still in use, support tickets per store per day, staff confidence survey scores. If adoption stalls in one store, the champion and manager follow up.

## Common mistakes

- Treating change as a single training session the week before go-live.
- Communications that announce what is happening but never explain why.
- Cutover plans with no owners, no timings or no rollback.
- Switching off the old system with no read-only access for look-ups.
- Declaring success at go-live instead of after adoption is measured.

## Quick recap

- ADKAR: awareness, desire, knowledge, ability, reinforcement; training covers only knowledge.
- Plan impacts, sponsors and champions, communications, role-based training and support.
- A cutover runbook lists every task with owner and time, go/no-go checkpoints, rollback and hypercare.

## Try it

In the Do tab you write a training plan and a cutover runbook.


Plan the people side of go-live: stakeholders, training, communications and a cutover runbook.

Change management

What is Organizational Change Management? | Introduction to Change Management

Cutover Plan: What Happens After Go Live

## Why it matters

Systems analyst job adverts often mention business analysis certifications, and some employers and government contracts prefer or require them. A certification will not replace experience, but it gives you a shared vocabulary with other analysts, a structured view of the whole discipline, and a signal to employers that you take the profession seriously. The key is choosing the right one for where you are now, because some require years of documented experience.

## The IIBA certifications

The [International Institute of Business Analysis (IIBA)](https://www.iiba.org/business-analysis-certifications/) offers a core ladder based on its guide, *A Guide to the Business Analysis Body of Knowledge* (the **BABOK Guide**):

| Certification | Who it is for | Experience needed |
|---|---|---|
| [ECBA](https://www.iiba.org/business-analysis-certifications/ecba/) (Entry Certificate in Business Analysis) | New analysts and career changers | None; requires business analysis training hours |
| [CCBA](https://www.iiba.org/business-analysis-certifications/ccba/) (Certification of Capability in Business Analysis) | Analysts with a few years' practice | Documented business analysis work experience |
| [CBAP](https://www.iiba.org/business-analysis-certifications/cbap/) (Certified Business Analysis Professional) | Senior analysts | Substantial documented experience across the BABOK knowledge areas |

IIBA also offers specialist certifications, for example in agile analysis, business data analytics, cybersecurity analysis and product ownership analysis.

The BABOK Guide organises the discipline into knowledge areas: business analysis planning and monitoring; elicitation and collaboration; requirements life cycle management; strategy analysis; requirements analysis and design definition; and solution evaluation. Most of this course and the Business & Systems Analysis course map directly onto them: stakeholder interviews (elicitation), process and data-flow models (requirements analysis and design definition), build-versus-buy (strategy analysis), and UAT and adoption measures (solution evaluation).

## The PMI option

The Project Management Institute (PMI), best known for the PMP, has offered a business analysis credential, the **PMI Professional in Business Analysis (PMI-PBA)**, aimed at analysts who work closely with project teams. PMI revises its certification portfolio from time to time, so check the [PMI certifications page](https://www.pmi.org/certifications) for the current name, eligibility and whether it is still open to new candidates before you plan around it.

The general difference in flavour: IIBA certifications cover business analysis as a discipline in its own right, while PMI's credential frames analysis within project and programme delivery.

Checked on 2026-10-23. Eligibility hours, training requirements, exam formats, fees and renewal rules all change. Read the official handbook on the IIBA or PMI site before you apply, and do not rely on numbers from videos, forums or this lesson.

## Choosing

- **New to analysis, or changing career?** The ECBA is the usual starting point because it requires no prior experience. Pair it with portfolio evidence: a process map, a set of user stories and a mapping document from your coursework.
- **A few years in?** The CCBA, or a specialist certificate that matches your role (for example agile or data analytics).
- **Senior, leading analysis on large projects?** The CBAP.
- **Working mainly inside a PMO or project-driven organisation?** Look at what PMI currently offers, and at what your employer recognises.
- **Ask your employer.** Many pay exam fees, and some have a preferred body.

## Logging experience

The senior certifications require you to document your experience, often by project, hours and knowledge area, and may require references. Start a simple log now, even if you are years away from applying:

```text
Project:   CRM replacement, Harbor Outfitters (coursework case)
Dates:     2026-10 to 2026-12
Hours:     40
Areas:     Elicitation (stakeholder interviews), Requirements analysis
           (DFDs, STTM), Solution evaluation (UAT scripts)
Evidence:  Diagrams and mapping in portfolio folder
Reference: Course instructor / team lead
```

Real job experience counts; coursework usually does not count toward experience hours, but logging it builds the habit and your portfolio.

## Common mistakes

- Paying for an exam you are not yet eligible for; check eligibility first.
- Memorising the BABOK without being able to apply it to a real case.
- Expecting the certificate alone to get you hired; portfolios and experience matter more.
- Relying on old blog posts for eligibility rules.

## Quick recap

- IIBA's core ladder is ECBA (entry), CCBA (some experience) and CBAP (senior), based on the BABOK Guide.
- PMI has offered the PMI-PBA; check its current status on the PMI site.
- Choose by experience level and employer recognition, check the official handbook, and start logging experience now.


Compare the IIBA and PMI business analysis certifications and choose one that fits your experience.

Analyst certifications

IIBA Certifications Explained: ECBA, CCBA, CBAP

Everything you need to know about the IIBA CBAP Certification

Plan user acceptance testing, training and cutover, and choose an analyst certification.

Solution Design & Integration

About this course

Course content

Systems Architecture

Integration

Delivery and Change

Where this course leads

Careers that use it