Migration Service Pack
To make the transition to CrateDB as smooth as possible, this Service Pack assists you during the data migration phase.
At CrateDB, we handle your data with care and it requires extra attention during the migration process. That's why we designed this optional Migration Service Pack, offering you special assistance by a dedicated team of solution engineers.
We established a process consisting of 5 distinct steps, as highlighted below. They can be easily adjusted after the initial discovery workshop.
Process Steps
Technical workshop
Objective: Lay the groundwork for a successful migration by understanding your current setup and future requirements.
- Define Target Architecture: Collaborate with your team to design the target architecture for CrateDB, ensuring it meets your performance and scalability needs.
- Identify Involved Tools: Determine the tools and technologies required for the migration process.
- Understand Constraints and Business Requirements: Gather detailed information about your constraints, business requirements, and objectives to tailor the migration approach.
- Define a Feasible Migration Approach and Timeline: Develop a comprehensive migration plan that minimizes disruption and ensures data integrity.
Duration estimate: up to one day
Data migration
Objective: Seamlessly transfer your data from InfluxDB to CrateDB while maintaining its integrity.
- Data Analysis: Perform an in-depth analysis of your current data, including volume, structure, and usage patterns, to inform the migration strategy.
- Architecture Review: Evaluate your existing architecture to identify potential challenges and ensure compatibility with CrateDB.
- Migrate Data: Execute the data migration process using optimized tools and methods to ensure a secure and efficient transfer.
Duration estimate: 5 to 10 days
Ecosystem integration
Objective: Ensure all applications and systems in your ecosystem are compatible with CrateDB.
- Review the Applications in the Ecosystem: Assess all applications that interact with your database to understand their requirements and dependencies.
- Determine Functional Equivalence: Ensure that CrateDB can provide the same functionalities as InfluxDB, identifying any gaps and addressing them.
- Establish Connectivity: Set up and verify connections between CrateDB and other systems in your ecosystem, ensuring seamless data flow.
Duration estimate: 2 to 5 days
Query migration
Objective: Adapt and optimize your existing queries to work efficiently with CrateDB.
- Identify Queries: Catalog all queries used in your InfluxDB environment to determine which needs to be migrated.
- Help Rewrite Queries: Assist in rewriting queries to ensure they are optimized for CrateDB’s query engine and syntax.
- Validate and Test Performance: Rigorously test the performance of migrated queries to ensure they meet or exceed your existing performance benchmarks.
Duration estimate: 2 to 5 days
Post migration
Objective: Provide ongoing support to ensure your CrateDB environment runs smoothly and addresses any issues promptly.
- Business-Critical Support: During this period, you will get business-critical support from the CrateDB team to handle any issues that arise post-migration, ensuring minimal downtime and disruption.
- Performance Monitoring: Regular monitoring and optimization to ensure your CrateDB environment performs at its best.
- Knowledge Transfer: Equip your team with the necessary skills and knowledge to manage and maintain the new CrateDB setup through comprehensive training sessions.
Duration estimate: 2 weeks after go-live
Migration Assets
CrateDB has assets that help customers migrate to CrateDB.
- The CrateDB Toolkit provides an easy way to migrate data. See this page page for a series of examples.
- CrateDB’s comprehensive SQL capabilities enable powerful query transformations, effectively mapping features.
- Because of the support for the PostgreSQL Wire protocol in CrateDB, most of the tools and applications are easily modified to connect to CrateDB.
Migration Options
Organic migration (Preferred option)
This most used option consists of configuring the ingest side of the pipeline, most of the time a message broker, to stream the messages both into the database to migrate and CrateDB. When the data retention period is crossed, the consumer side can be gradually reconfigured until all pipelines are changed.
Pros:
- Time to test: Pipelines can be gradually reconfigured and tested.
- Low risk: Data is ingested in two databases simultaneously, so the data remains always available.
- Gradual shift: Tools can shift gradually, allowing sufficient time to troubleshoot any issues early.
Cons:
- Two databases need to be maintained for at least the retention period.
Cutover migration
A Cutover migration for databases is a method of migrating from your existing database to CrateDB in a single, planned event, typically with minimal downtime. Data is migrated and updated incrementally until the cut-over time. At the cut-over time, all consuming applications need to point to the new database.
Pros:
- No need for two database platforms for a long period.
Cons:
- High-risk operation (not everything can be tested before cut-over)
- No proper fallback