Section 2: Business Requirements and Data Analysis. Lesson 7.
Before any data can move, the migration team must know exactly where the data lives today (the source) and where it will live afterwards (the target). This step shapes the whole project: it defines the scope, the effort estimate, the technical challenges, and the choice of tools and strategy.
Data sources
A source can be an internal system, a single application, or many systems at once. Business owners and stakeholders usually know which systems hold the data, but not always every copy. Common source categories:
- CRM (customer relationship management): Salesforce, Zoho CRM, Pipedrive, HubSpot. Hold customer, lead, deal and activity data at large scale.
- ERP (enterprise resource planning): SAP, Oracle NetSuite, Microsoft Dynamics, Odoo. Software that manages and automates core business processes such as finance, inventory, procurement and HR.
- Operational databases behind in-house applications and websites (for example the reviews table behind a business website)
- Files: spreadsheets, CSV exports, shared drives, document stores
- SaaS tools reachable only through APIs or exports
- Legacy platforms: mainframes, flat files, old database versions
Source inventory checklist
- System name, owner and business purpose
- Technology and version (for example MySQL 5.7, Salesforce API v59)
- How to access it: direct DB connection, API, export files; credentials and rate limits
- Objects and tables in scope, with record counts and data size
- Data quality notes, sensitive fields (PII, financial) and how often data changes
- Which system is the system of record when the same data exists in several places
Target systems
The target defines where data goes after migration. Its structure, data types, storage capacity and business rules shape how the data must be transformed and loaded, so understanding it matters as much as understanding the source. A target is usually one of three kinds:
- A database
- Cloud storage or a cloud platform
- Another legacy system: not every migration is an upgrade. Sometimes data moves sideways between systems of the same generation, for example after a merger or a vendor change.
Databases
MySQL is an open-source RDBMS (relational database management system). It uses SQL to create and manage databases and stores data in structured tables of rows and columns. It suits structured records such as customers, orders and numerical or analytical data. Large binary files such as images and videos are better kept in object storage, with only a reference stored in the database.
PostgreSQL is an advanced, enterprise-grade open-source RDBMS. It is known for reliability, strict ACID compliance and a rich feature set: JSONB, full-text search, extensions such as PostGIS, and custom types and functions.
ACID means Atomicity (all or nothing), Consistency (rules are always respected), Isolation (concurrent transactions do not interfere) and Durability (committed data survives crashes). These guarantees matter in a migration because a half-loaded batch must never be left behind.
Cloud platforms
- AWS (Amazon Web Services): reliable, scalable, pay-as-you-go services such as S3 (object storage), RDS and Aurora (managed databases), Redshift (warehouse) and DMS (migration).
- Microsoft Azure: widely used in corporate environments, especially Microsoft shops. Blob Storage, Azure SQL, Synapse, Azure Database Migration Service.
- Google Cloud (GCP): Cloud Storage, Cloud SQL, BigQuery (a strong analytics warehouse), Database Migration Service.
Legacy systems
Legacy storage typically includes mainframes (IBM z/OS with DB2, IMS, VSAM), tape drives used for archives and backups, hierarchical and network databases and flat file systems, and older relational database versions that are out of support. They can appear as sources (most often) or, occasionally, as targets.
Source and target assessment
A thorough assessment of both sides reduces migration risk by surfacing compatibility issues before they become production problems. Compare:
- Data types and precision (for example a source DATETIME with no time zone into a target TIMESTAMPTZ)
- Field lengths and required fields (a target NOT NULL column with missing source values)
- Keys and relationships (natural keys against surrogate IDs)
- Character encoding and collation
- Capacity, performance limits and API quotas on the target
- Business rules and validations the target enforces
Multiple sources and consolidation
Many real migrations pull from several sources into one target, for example customers held in a CRM, an ERP and a billing system. Data from different sources must then be:
- Consolidated: merged into one dataset
- Standardised: common formats, codes and units
- Transformed: reshaped to the target schema
- Deduplicated: matching rules decide when two records are the same entity, and survivorship rules decide which value wins
CRM (Salesforce) ──┐
ERP (SAP) ──┼──▶ Transform / standardise / dedupe ──▶ Target (PostgreSQL / cloud)
Billing DB ──┘This is why data transformation runs through the whole migration, not just one step of it.
Tying it back to stakeholder requirements
Sources and targets are confirmed with stakeholders, not assumed. For the running reviews example, the checklist stays the same: no backup exists, find the website's developer, keep communication clear, define the migration scope, set success criteria, and get approval before migrating. Checking expectations at each step keeps the technical plan aligned with what the business wants.
Key takeaways
- Identify every source (CRM, ERP, databases, files, SaaS, legacy) and record owner, access, volume and quality.
- The target can be a database, the cloud or even another legacy system, and its constraints drive the transformation.
- Assess source against target early to catch compatibility issues.
- Multiple sources mean consolidation, standardisation and deduplication.
Next: 8. Stakeholder Requirement Gathering.