Services
SERVICES
SOLUTIONS
TECHNOLOGIES
Industries
Insights
TRENDING TOPICS
INDUSTRY-RELATED TOPICS
OUR EXPERTS
AWS to AWS migration for a transportation intelligence provider
The customer required a quick migration of their product ecosystem to a new AWS organization. Itransition performed the migration of the customer’s complex infrastructure, ensuring business continuity and data consistency.
Zero
downtime
100%
data consistency
50TB
of data migrated
All technologies used
Engagement model
About the customer
The customer is a data and analytics provider based in EMEA, focused on delivering operational and market insights for global logistics and transportation. Their solutions support operational visibility, enhance logistics operations, and provide transport activity analysis in the sector.
Company type
Private
Domain
Information services, Data & analytics
Geography
EMEA
Specialization
Logistics & transportation intelligence
The challenge
As part of corporate restructuring, the customer needed to migrate their products to a new AWS organization. The challenge was to ensure a smooth, yet quick transition to the new infrastructure maintaining solution operability with minimum downtime to ensure business continuity.
The solution
At a glance
Itransition analyzed the customer’s AWS infrastructure, selected the most optimal migration approach, and migrated the solution gradually to ensure its availability and minimum downtime.
Preparation
The customer’s existing AWS infrastructure was complex, housing multiple products, both new and long-running and serving a large number of end clients. The overall data volume amounted to 50TB with 1TB of real-time data processed daily.
The main migration strategy was Lift and shift – migrating the current infrastructure as is to another AWS account via the AWS toolset and without significant re-development efforts. We refrained from the big bang migration approach – one-step migration that assumes transitioning all resources at the same time within a specific time period – to reduce risks related to service disruption and data inconsistency, avoid extensive testing, and cut costs and decided to migrate the product gradually. To ensure solution availability and minimum downtime, we aimed to enable a mixed working setup with the source and target accounts functioning in parallel during the transition period.
Our team split the entire migration scope into several streams, with their order defined by data flow consequence as there were interdependencies between different parts of the infrastructure. This way, it became possible to migrate infrastructure in smaller chunks. Apart from the core streams, we outlined secondary streams that had no or only indirect dependencies on the core app, and their migration order was not critical.
Migration
Migration streams occurred progressively in accordance with data flow dependencies. This approach offered the most simple and logical realization in terms of 2 accounts working in parallel (cross-account mode) and allowed for easier app maintenance without serious alterations. Some services continued functioning on both source and target accounts until interdependencies with the entities to be yet migrated disappeared and because not all legacy apps supported the cross-account mode.
Migration was conducted using the most out of the AWS toolset and data migration services. The parts of the infrastructure that had already been supported by automated Terraform scripts were re-created in the new AWS account, for the majority of legacy apps we created machine snapshots, moved them to the target account, and restored them to the working state.
As there was no information on some legacy systems and their configuration, it was not possible to migrate them as a snapshot. Our team had to reverse-engineer legacy apps and configure them from scratch to ensure their operability, with the customer’s team providing guidance, necessary details, and verification. We also collaborated with other vendors, who were working on third-party products and related solutions being part of the customer’s ecosystem, and prepared the platform for deploying their products.
Main streams
- Stream 1
Migrating the data ingestion pipeline. The SNS topic in the target account continued sending data to the SQS queues in the source account until their further migration. - Stream 2
Recreating and launching a data archiving app and associated object storages (Athena, S3) in the target account. - Stream 3
Migrating legacy apps together with the associated SQS queues and the dedicated database, subscribing apps to their corresponding SQS queues in the target account. - Stream 4
Recreating and launching data ingestion and job scheduling nodes (5 EC2 autoscaling groups), SQS and RabbitMQ queues, restoring Elasticsearch clusters backup in the target account. - Stream 5
Making the Aurora and RDS databases snapshot and restoring them in the target account. - Stream 6
Recreating the API in the target account. API Gateway was used to handle API calls, where some of the requests occurred via static IPs as some end clients wished that for security reasons. To address this particularity on a multi-regional scale, we applied a combination of custom DNS and various API Gateway configurations. - Stream 7
Deploying the web interface in the target account and performing the DNS switchover on the scheduled date, being a final important step.
Secondary streams
- Stream 1
Creating a copy of the CI/CD pipeline in the target account and gradually transitioning to it in parallel with migrating the app components related to CI/CD jobs. - Stream 2
Migrating microsites along with the related database. - Stream 3
Migrating the Redshift database and restoring it in the target account. We selected and deployed the most powerful type of the Redshift cluster, temporarily increasing target capacity to handle the full data migration and restoration in just a few hours instead of days. - Stream 4
Recreating and launching the static data ingestion tool in the target account, reconfiguring it to work with the dedicated database. - Stream 5
Creating the infrastructure for a third-party predictive analytics app and conducting the initial setup of the database and infrastructure parts related to the app.
Looking for an experienced cloud migration provider?
The outcome
Itransition migrated the customer’s infrastructure to the new AWS organization, ensuring seamless data synchronization between two AWS accounts during the transition period. This enabled the customer to maintain uninterrupted business operations, while preserving data consistency.
01
Zero downtime
02
100% data consistency
03
50TB of data migrated
Related cases
Case study
Billing & sample storage management platform upgrade
Itransition modernized the customer’s billing and sample storage management platform, upgrading backend and frontend and migrating it to a modern tech stack.
Case study
Salesforce environment modernization for a technology provider
Itranstion migrated the customer’s Salesforce-based CRM to Lightning, implemented a multi-system integration solution, and introduced an automated feature delivery process.
Case study
Fintech ITSM improvement and cloud migration
Learn how Itransition optimized legacy ITMS processes and migrated Atlassian Jira and Confluence instances to the cloud for a fintech provider.
Case study
BI system modernization for order management
Learn how we revamped a BI system via ETL process setup, report migration, data warehouse development, and other improvements, achieving faster data delivery.
Case study
Microsoft Power Platform CRM for a legal organization
Learn how Itransition built a Power Platform CRM to speed up will management and case handling, centralize related workflows, and automate client notifications.
Case study
Cloud business intelligence system for vehicle manufacturers
Find out how Itransition migrated a BI suite to the cloud and delivered brand-new cloud business intelligence tools for the automotive industry.