- Undocumented dependencies cause 40% of mid-migration rollbacks because teams discover hardcoded connections, shared databases, and file system links only after workloads move to AWS.
- Organisations that skip compliance planning face 4 to 8 week delays when auditors or customers discover gaps in data residency controls, encryption standards, or access management during the transition period.
- SMBs with fewer than 5 cloud engineers experience 60% longer migration timelines when they lack documented runbooks, because knowledge concentration in one or two individuals creates single points of failure.
Why This List Matters
CTOs, Heads of Engineering, and IT Directors in European SMBs approve AWS migrations expecting faster deployments, lower infrastructure overhead, and better disaster recovery. Engineering teams know the benefits are real but also understand that poorly executed migrations create hybrid architectures more expensive and fragile than the legacy systems they replace.
The challenges in this list are ranked by how frequently they cause migration failure or significant timeline extension. Each challenge includes specific prevention measures so teams can build mitigation into their migration plan from the start, rather than discovering problems mid-flight. For SMBs with 50 to 500 employees, getting the migration right on the first attempt is critical because the budget and timeline for a second attempt rarely exist.
Regulated industries face additional pressure. Financial services, healthcare, insurance, and B2B SaaS organisations must maintain continuous compliance throughout migration. A compliance gap during transition can trigger audit findings, customer escalations, or regulatory action regardless of how well the migration performs technically.
1. Underestimating Application Dependencies and Interdependencies
Impact level: Critical. Causes the highest rate of emergency rollbacks during active migration.
What happens: Teams migrate an application to AWS and discover it depends on services, databases, or file systems that remain on premises. Hardcoded IP addresses, shared database connections, internal DNS entries, and file path references break silently or catastrophically when the application moves to a new network environment. The AWS Migration Lens identifies dependency discovery as a foundational requirement before any workload movement begins.
Why it ranks first: Dependency failures happen during live migration windows when pressure to proceed is highest. Teams that discover a broken dependency at 2am during a production cutover face an immediate choice between extending downtime to investigate or rolling back entirely. Both options are expensive. Undocumented dependencies are the primary reason migrations that passed testing environments fail in production.
How to avoid it
- Run automated dependency discovery tools such as AWS Application Discovery Service or open source alternatives across all environments at least 6 weeks before migration begins
- Map every application’s inbound and outbound connections including database links, API calls, file shares, message queues, and scheduled jobs that reference other systems
- Test dependency maps in a staging environment that mirrors the target AWS architecture before attempting production migration
Warning signs you are at risk
- Infrastructure documentation is more than 12 months old or does not exist
- Applications were built by engineers who are no longer with the organisation
- No one on the team can draw the complete architecture diagram from memory
2. Inadequate Data Classification and Compliance Planning
Impact level: High. Creates legal and regulatory exposure that can halt migrations entirely.
What happens: Organisations move data to AWS without classifying what they hold, where it originates, or what regulatory requirements apply. Personal data ends up in the wrong AWS region. Encryption requirements are missed. Data processing records required under GDPR Article 30 become incomplete or inaccurate during the transition. Customers or auditors discover compliance gaps that force immediate remediation or migration rollback.
Why it ranks here: Compliance failures carry consequences beyond project delays. GDPR enforcement data shows that data protection authorities have issued billions in fines since 2018, with inadequate technical and organisational measures among the most common violations. For SMBs selling into enterprise customers, a compliance gap discovered during migration can trigger customer audit escalations that damage commercial relationships regardless of technical migration success.
How to avoid it
- Complete a data classification exercise covering all data stores before migration planning begins, documenting data type, sensitivity, regulatory obligations, and residency requirements
- Confirm AWS region selection satisfies data residency requirements for every classified dataset, particularly personal data from EU residents
- Maintain parallel compliance controls in both source and target environments throughout the transition period until the source environment is fully decommissioned
Warning signs you are at risk
- No current data inventory exists or the last classification was completed more than 18 months ago
- The team cannot identify which databases contain personal data subject to GDPR
- Customer security questionnaires ask about data residency controls and the team cannot provide documented answers
3. Applying a Single Migration Strategy Across All Workloads
Impact level: High. Either delays the entire migration or creates long-term technical debt.
What happens: Teams decide to rehost everything (lift and shift) or refactor everything (re-architect for cloud native) without evaluating each workload individually. Rehosting everything moves applications to AWS quickly but carries forward every existing architectural limitation. Refactoring everything extends timelines by 60 to 80% and introduces re-engineering risk to production systems that were functioning adequately. The AWS 7 Rs migration strategies framework exists specifically to prevent this one-size-fits-all approach.
Why it ranks here: Strategy mismatches compound over time. A legacy monolith that should have been refactored but was rehosted requires the same manual scaling, the same deployment complexity, and the same operational overhead it had on premises. Conversely, a stable internal tool that was refactored into microservices when a simple rehost would have sufficed consumed 4 to 6 months of engineering time without meaningful operational improvement.
How to avoid it
- Evaluate each workload against the 7 Rs framework considering business criticality, technical complexity, and operational requirements before assigning a migration strategy
- Rehost mission-critical production systems first to establish AWS operational patterns, then schedule refactoring as a separate initiative with its own timeline and budget
- Retire or decommission unused systems before migration begins to reduce scope and eliminate unnecessary workload movement
Warning signs you are at risk
- The migration plan uses the same approach for every application regardless of architecture or business value
- Engineering leadership has not evaluated which systems should be retired rather than migrated
- No one has assessed which workloads would benefit from AWS managed services versus simple compute hosting
4. Security Gaps During the Transition Period
Impact level: High. Creates a window of increased vulnerability when both environments are active.
What happens: During migration, organisations operate in a hybrid state where workloads exist in both on-premises and AWS environments simultaneously. Security controls designed for a single environment do not automatically extend to cover both. IAM policies, network security groups, encryption configurations, and audit logging must be implemented in AWS before production workloads arrive. The AWS Shared Responsibility Model makes this explicit: AWS secures the infrastructure, but customers are responsible for securing everything they deploy on it.
Why it ranks here: The transition period is when security posture is weakest. Temporary network connections between environments create attack surface that did not exist before migration. Firewall rules are broadened to allow data transfer. Service accounts are created with excessive permissions to avoid blocking migration progress. These “temporary” configurations frequently become permanent when teams move to the next phase without cleanup. Organisations pursuing or maintaining ISO 27001 certification face particular risk because auditors examine security controls across all active environments, including transitional ones.
How to avoid it
- Implement AWS security foundations before any workload migration including IAM with least-privilege policies, VPC network isolation, encryption at rest and in transit, and centralised CloudTrail logging
- Document and schedule removal of all temporary access created during migration, with automated expiration where possible
- Run security validation after each migration wave to confirm controls are active and no temporary configurations remain
Warning signs you are at risk
- The migration plan does not include a security workstream running in parallel with workload movement
- IAM policies use wildcard permissions or broad access grants to avoid “slowing down” migration
- No scheduled review exists for temporary network rules or service accounts created during migration
5. Insufficient Rollback and Disaster Recovery Planning
Impact level: Medium to high. Turns recoverable problems into extended outages.
What happens: Teams plan the forward migration path in detail but treat rollback as an afterthought. When a workload fails after cutover, the team discovers that the rollback procedure was never documented, tested, or rehearsed. Data written to the new environment after cutover creates synchronisation conflicts with the source environment. DNS changes propagated to external clients cannot be reversed quickly. What should have been a 30 minute recovery becomes a multi-day incident.
Why it ranks here: Rollback failures escalate manageable migration issues into business-impacting outages. A database migration that encounters a schema incompatibility is a technical problem with known solutions. The same issue without a tested rollback procedure becomes an extended outage while engineers improvise recovery under pressure. According to the AWS Well-Architected Framework, reliability pillar best practices require documented and tested recovery procedures for all production workloads.
How to avoid it
- Document a rollback procedure for every workload migration including specific steps, responsible individuals, estimated recovery time, and data synchronisation requirements
- Test rollback procedures in staging environments before each production migration wave, including scenarios where partial data has been written to the target environment
- Maintain source environments in operational state for a minimum of 2 weeks after each production cutover to ensure rollback remains viable
Warning signs you are at risk
- The migration plan includes detailed forward steps but no documented rollback procedure
- Source environments are scheduled for decommission immediately after cutover
- The team has never rehearsed a rollback scenario for any migrated workload
6. Skills Gaps and Knowledge Concentration in Small Teams
Impact level: Medium. Slows migration progress and creates single points of failure.
What happens: SMBs with 50 to 200 employees typically have 2 to 5 engineers with infrastructure responsibilities. When these engineers lack AWS experience, every migration decision requires research, experimentation, and learning that extends timelines. When only one engineer understands the migration architecture, their unavailability due to illness, leave, or departure halts the project entirely. Puppet’s State of DevOps research consistently shows that team capability and knowledge sharing are primary predictors of deployment success.
Why it ranks here: Skills gaps do not cause sudden failures. They cause steady accumulation of suboptimal decisions, configuration drift, and undocumented workarounds that create problems months after migration completes. The engineer who configured the VPC networking leaves, and no one understands why specific routing rules exist. The database administrator who chose RDS instance sizes moves on, and the replacement cannot explain the sizing rationale. Knowledge concentration is invisible until the person holding it is unavailable.
How to avoid it
- Pair internal engineers with external cloud specialists during the migration itself to transfer knowledge through hands-on collaboration rather than classroom training
- Document every architectural decision in architecture decision records (ADRs) that explain not just what was chosen but why, and what alternatives were considered
- Require at least two engineers on every migration runbook so that no single person holds exclusive knowledge of any critical procedure
Warning signs you are at risk
- Only one engineer on the team has completed any AWS certification or has production AWS experience
- Migration planning and execution depend on a single individual whose absence would halt the project
- Architectural decisions are made verbally or in chat messages without formal documentation
7. Post-Migration Performance Degradation and Cost Overruns
Impact level: Medium. Erodes the business case for migration after the project completes.
What happens: Workloads migrated to AWS perform differently than they did on premises. Applications that relied on low-latency local network connections now communicate across VPCs with higher latency. Databases migrated without query optimisation consume more compute and storage than anticipated. Development and staging environments run 24/7 in AWS when they only ran during business hours on premises. Within 3 to 6 months, AWS bills exceed projections by 30 to 60%, and leadership questions whether the migration delivered its promised benefits. McKinsey’s FinOps research shows that organisations implementing active cloud optimisation reduce waste by 20 to 30% without reducing capacity.
Why it ranks here: Performance and cost issues do not prevent migration from completing. They undermine the business case after the fact. The CTO who approved migration based on projected efficiency gains faces difficult conversations when actual costs exceed forecasts. Engineering teams lose credibility and budget for future initiatives. The worst outcome is when performance degradation causes teams to maintain both environments indefinitely, running hybrid infrastructure at premium operational overhead.
How to avoid it
- Establish performance baselines before migration for every critical workload including response times, throughput, error rates, and resource utilisation
- Implement AWS CloudWatch monitoring and AWS Cost Explorer from the first production migration wave with alerts configured for performance degradation and budget thresholds
- Schedule rightsizing reviews at 30, 60, and 90 days post-migration using AWS Compute Optimiser and Trusted Advisor recommendations
Warning signs you are at risk
- No performance baselines exist for current on-premises workloads to compare against post-migration performance
- The migration budget does not include a line item for post-migration optimisation and monitoring
- Development and staging environments have no automated shutdown scheduling
When Lower-Ranked Challenges Become Primary
Large-scale data migrations: Organisations migrating more than 100 TB to AWS find that Challenge #2 (data classification) and Challenge #5 (rollback planning) dominate the project. Transfer logistics, bandwidth constraints, and data validation at scale require dedicated planning that overshadows all other challenges. AWS Snowball and DataSync become critical tools and data integrity verification extends timelines by 4 to 8 weeks.
Highly regulated industries: Financial services organisations subject to DORA and healthcare providers under patient data regulations elevate Challenge #4 (security gaps) above all others. Regulatory frameworks mandate continuous documented controls throughout migration, meaning security is not just a parallel workstream but a prerequisite for each migration wave.
Teams with zero cloud experience: SMBs where no engineer has production AWS experience find Challenge #6 (skills gaps) becomes the blocking factor from day one. Without foundational cloud competence, teams cannot effectively address any other challenge on this list. Engaging external cloud specialists before migration begins is not optional for these organisations.
Acquisitions and mergers: Companies migrating inherited infrastructure from an acquired business face Challenge #1 (undocumented dependencies) at extreme scale. The acquiring team has no institutional knowledge of the target systems, documentation is typically incomplete or outdated, and the engineers who built the original systems may no longer be available.
Real-World Decision Scenarios
Scenario: Insurance Technology Company Migrating Customer Data Platform
Profile:
- Company size: 120 employees
- Target market: European insurance carriers
- Current state: On-premises data platform processing claims and customer records, 15 TB total data
- Cloud experience: Limited, 2 engineers with AWS Associate certification
- Compliance: GDPR, incoming DORA obligations, customer audits quarterly
Primary challenges: #2 (data classification) and #4 (security gaps)
Rationale: Insurance customer data includes sensitive personal and financial information subject to multiple regulatory frameworks. Data classification must happen before any migration planning because the wrong AWS region selection or inadequate encryption creates legal exposure. Security controls must be validated and documented before workloads move because quarterly customer audits will examine the transition period. Partners like HST Solutions, which hold ISO 27001 and ISO 22301 certification, can embed cloud engineers who bring both migration expertise and compliance documentation experience from day one.
Expected outcome: Complete data classification and security framework in weeks 1 to 6. Migrate non-production environments in weeks 7 to 14. Move production data platform with zero-downtime cutover in weeks 15 to 24. Pass first post-migration customer audit with full documentation of transition controls.
Scenario: B2B SaaS Company Scaling Across EU Markets
Profile:
- Company size: 75 employees
- Target market: Enterprise customers in 4 EU countries
- Current state: Single AWS region, manual deployments, no infrastructure as code
- Cloud experience: Moderate for application hosting, limited for infrastructure management
- Growth stage: Series A, expanding to 3 additional EU markets in 12 months
Primary challenges: #3 (single migration strategy) and #6 (skills gaps)
Rationale: Expanding from one AWS region to multiple regions across the EU is effectively a migration, even though the company is already on AWS. Each market may require workloads in specific regions for data residency. The existing manual deployment process will not scale to multi-region operations. The team needs both a strategy-per-workload approach to decide what moves where and external cloud expertise to design multi-region infrastructure they have never built before.
Expected outcome: Evaluate workloads and design multi-region architecture in weeks 1 to 4. Implement infrastructure as code and CI/CD pipelines in weeks 5 to 12. Deploy to additional EU regions with automated provisioning in weeks 13 to 20. Achieve multi-region operational maturity with unified monitoring by month 8.
