STACKIT 5: Migrating from AWS A Practical Checklist
Moving from AWS to STACKIT is a planned infrastructure migration, not something you try to force through over a weekend. The process is structured, the risks are manageable, and for most standard workloads the final cutover can usually be measured in minutes rather than hours. This checklist covers the full sequence.
One STACKIT-specific note before the phases: STACKIT onboarding is more enterprise-focused than some cloud providers. New customer accounts are provisioned through a STACKIT sales process rather than a fully self-serve sign-up. Please build that into your timeline; account provisioning may take several business days.
Phase 1: Audit and Inventory
Document your full AWS footprint before making any changes.
- List every AWS service currently in use across all accounts and regions.
- Document instance types, database engines and versions, storage volumes, and cross-region configurations.
- Map all inter-service dependencies, including what connects to what, connection strings, endpoint formats, and authentication methods.
- Identify all applications and scripts that rely on AWS-specific APIs or SDKs, especially Kinesis, SQS, SNS, and Lambda, where the STACKIT equivalent uses a different API.
- Classify data by sensitivity and compliance requirement, including which datasets have specific residency or access control needs.
- Separate stateless workloads, which are easier to migrate, from stateful workloads, which need more detailed data migration planning.
Phase 2: STACKIT Account Setup
- Contact STACKIT to begin account provisioning. STACKIT accounts are set up through the enterprise sales process.
- Once provisioned, create projects, which are STACKIT’s organisational unit and roughly equivalent to AWS accounts within an organisation.
- Configure IAM. STACKIT uses a role-based access control model, so map your current AWS IAM roles and policies to the closest STACKIT equivalents.
- Set up billing alerts and cost tracking from the start.
- Create a dedicated test project that is separate from production.
Phase 3: Networking
- Create Virtual Private Cloud networks for each project. STACKIT supports standard OpenStack networking.
- Configure Security Groups for instance-level access control.
- Set up a Load Balancer if your architecture needs one. STACKIT provides managed load balancing.
- Configure DNS in STACKIT DNS and import your current DNS zone as a starting point.
- Do not update live DNS records yet. DNS changes should be the final cutover step.
Phase 4: Data Migration
- Object Storage: use rclone or the AWS CLI with STACKIT’s S3-compatible endpoint to synchronise S3 buckets. Run an initial full sync, then a delta sync immediately before cutover.
- Relational databases (PostgreSQL, MariaDB): export from RDS using pg_dump or mysqldump. Import into STACKIT Managed Database. Verify row counts and run integrity checks before moving on.
- MongoDB: use mongodump and mongorestore to migrate from DocumentDB to STACKIT MongoDB Flex. Verify index structure after import.
- Redis: use redis cli DUMP and RESTORE for cache migration where cache warming is not practical. For most caching workloads, letting the cache rebuild naturally is simpler.
- For stateful applications: coordinate data migration with a planned maintenance window so source and destination do not drift apart during migration.
Phase 5: Messaging Migration
This phase requires code changes if you are moving from SQS, SNS, or Kinesis, because STACKIT’s managed messaging service is RabbitMQ, which uses the AMQP protocol instead of the AWS SDK messaging APIs.
- Identify all producers and consumers of SQS queues, SNS topics, and Kinesis streams.
- Replace AWS SDK messaging calls with an AMQP client library, such as amqplib for Node.js or pika for Python.
- Map SQS queues to RabbitMQ queues. Map an SNS topic fan-out to RabbitMQ exchanges with multiple bindings.
- For Kinesis streams, assess RabbitMQ Streams as the closest equivalent. Benchmark throughput using representative data volumes before making a final decision.
- Test all messaging flows thoroughly in the test environment before promoting to production.
Phase 6: Application Deployment
- Deploy applications to STACKIT Compute Engine instances or SKE, using your existing deployment tooling.
- Update all environment variables and configuration to point to STACKIT endpoints, including database hosts, Object Storage endpoints, and RabbitMQ connection strings.
- Run the full application against migrated data in the STACKIT test environment. Treat this as a production equivalent test.
- Run your full test suite and resolve any failures before moving forward.
Phase 7: Parallel Running
- Keep the AWS environment running and serving live traffic.
- Run the STACKIT environment in parallel and monitor performance and behaviour closely.
- For databases: maintain replication from RDS to STACKIT Managed Database during this phase so the data stays in sync.
- Resolve any performance gaps or behavioural differences before cutover.
- Parallel running increases cost for a short period, but it removes much of the rollback risk. For production workloads, it is usually worth the extra spend.
Phase 8: DNS Cutover
- Lower DNS TTLs to 60 seconds, 24 to 48 hours before cutover.
- At cutover, update DNS records to point to STACKIT IP addresses.
- Monitor traffic in real time using STACKIT Observability and your own application monitoring.
- Keep AWS running as a fallback for 24 to 48 hours after cutover.
Phase 9: Decommission
- After 48 to 72 hours of stable operation on STACKIT, begin terminating AWS resources.
- Delete S3 buckets, RDS instances, EC2 instances, and Load Balancers.
- Handle any Reserved Instance commitments in line with AWS modification and termination processes.
- Update runbooks, documentation, and monitoring dashboards so they reference STACKIT.
Ready to Have a Conversation?
If you have read this series and recognised your organisation in it, the next step is simple. Get in touch. We will have a chat, ask a few questions, and give you an honest view of what is involved. No charge. No obligation.
Back to: Migrate from AWS to Stackit Series
