AWS Database Migration Service Reviews

We are using AWS Database Migration Service for our data migration from our RDS, Oracle database from on-prem or cloud to moving this data into AWS ecosystem, S3, and then into Snowflake. We are using AWS Database Migration Service, and now we are on a journey of onboarding the stream platform.

The cost effectiveness of AWS Database Migration Service is good as it is quite cost effective. The scalability option is another valuable feature because AWS provides its own compute behind it, so I can scale up and scale down at any given point.

The security features of AWS Database Migration Service, such as encryption and IAM integration, are good.

We have the continuous data integration feature, but it does not work very well in our given ecosystem because we have huge data volume, and it reads from archive log rather than the redo sequence. That is where it lacks, so we are not able to do continuous streaming data injection.

The ability to handle heterogeneous migrations for our organization is adequate. I do not see a major value add, or see it as a marquee feature. It is a good tool, but we do not have that sort of uses requirement. In my 10 plus years of experience, I do not see that kind of requirement where I have to replicate it in real time.

I leverage AWS CloudWatch for addressing migration issues. The major challenges come across CDC. We have created latency filter and everything, but there is no way to control it. Due to the nature of our business, the transactions increase during month end and year end. My transactions are supposed to increase, my workloads on my core system increases, but my DMS is not able to keep up with them, even if I increase it to a higher side.

Improvements could be made in AWS Database Migration Service. Because of that, I am moving out of DMS now to a STRIIM solution. DMS works within AWS ecosystem, but they also have to look for third party solutions. Now Snowflake is a bigger player, or Databricks. Something that could be possible as a connector, whether paid or free, but giving as a connector to that ecosystem as well.

We have been using the solution for five years.

The installation and deployment of AWS Database Migration Service is straightforward. If I am able to predict some loads, I can increase the capacity, spin up a new DMS instance just for my one-time load activity when onboarding a new system. If I do not want to have an impact on existing pipeline, I can onboard a new DMS instance for one-time activity, or DMS serverless, move ahead, and then again move back to my existing installation.

AWS Database Migration Service is easy to maintain. The only concern is that the patching window is huge.

The service is easy to maintain with one person automatically. My infrastructure team handles this, and we have taken it as automatic. For DMS version upgrades, we schedule downtime during business hours so that midnight workloads are not interrupted and morning business can run smoothly. This is a quarterly activity, not continuous. Minor version upgrades are handled by DMS automatically. For major version upgrades, we need downtime, but it is very manageable and not a bottleneck.

While scalability is good, latency exists due to our business nature, and AWS Database Migration Service or AWS is not able to help in this regard. I have raised many cases and spoken to AWS SMEs and expert solution architects, but it remains limited.

I am happy with the technical support from AWS, but the product enhancement that is supposed to happen is not there. On a scale of one to ten points, I would rate tech support as seven.

Neutral

AWS Database Migration Service has definitely helped save money, but not time.

Regarding money savings, I can specify savings of around 40 to 60%. I have another benchmark as an ETL, ELT tool. If you take a legacy ETL tool within any data enterprise ecosystem, they will have Informatica, ODI, but they do not have a big data connector to connect to S3, Snowflake, or Redshift directly. I have to use Glue, PySpark, Python, or Airflow kind of custom made connector, but I have to give them heavy compute. Compared to DMS, those are expensive solutions. I am able to save around 40 to 60%. Otherwise, I would have to migrate those pipelines to Glue because that is the only ETL option in my arsenal. If I had Informatica cloud or Talend as a solution, I would have gone through that particular route. Here it is saving me around 40 to 60%, but for streaming solutions, I have to go for an expensive situation.

We required the AWS Schema Conversion Tool in very smaller capability. We have an enterprise data lake which acts as a landing layer. We do not require it in a very high context because schema conversion would be from one database to another database. We do not do that kind of heavy migrations. First we land everything within our AWS ecosystem, then move it into Snowflake.

AWS Database Migration Service is affordable and cheaper. However, it is not able to solve our critical needs.

If anyone has questions or comments about my review, they can reach me by email.

I rate AWS Database Migration Service as nine out of ten.

We were planning AWS Database Migration Service and migration services for one of our customers.

We used AWS Database Migration Service for legacy modernization. The work was completed last year.

The migration was from Oracle to Postgres. We had one more migration which involved MongoDB and Oracle on-premises to DynamoDB.

The transformation capabilities are valuable. Easy transformation and synchronization of changes in the database whenever there is change data.

The synchronizations on a weekly basis and monthly basis were good.

We implemented it using our stage canary option, where there's a near-prod environment, and then we sync it and switch over every week.

The Schema Conversion Tool was excellent.

We used it for encryption for data transfers and IAM roles which provided connectivity to the databases and user roles. This was excellent because we didn't have to create any new users, which could have been difficult previously.

One drawback I experienced was with balance and sync. When data was transferred, there was no easy way to log that. If a table had specific conditions, we had the possibility of having custom queries incorporated as part of the job execution. We had to use Airflow or similar tools at the end to do the custom jobs and validations for balance and sync. This was difficult because while we assumed everything would be good, for some reporting aspects, it was not very helpful as we had to write our own job to report.

We used the solution for two years.

We had one-to-one mapping without any straightforward issues. The only scenario was MongoDB to DynamoDB, which was easy without any heterogeneous aspects.

For failure cases, we could note the timing and fix it. We handled failure cases separately with a job that would compare datasets. We did not use any AWS features except for error conditions and alerts.

The solution was stable.

We limited scalability in terms of our approach. We did not do a direct production move but rather a staging move. Even if there was a failure, we could catch it and rerun it. Performance and scalability were not criteria for us because we had additional environments procured in AWS to support this.

We managed most issues in-house. During the first couple of months when setting up, we involved AWS engineers for a couple of calls. After that, we did not experience any major issues.

Positive

We used Informatica and custom code with Spark EMR for big data options.

The setup was completed and finished successfully.

Both our organizations were APN partners.

In our product comparison, the return on investment was much better. For very long-running processes with multiple interaction points and heterogeneous systems, it might have been slightly different, but in our case, it was the best option.

AWS Database Migration Service is much cheaper regarding licensing and total cost of ownership compared to other solutions. Informatica had better transformation features and more plugins, such as REST to data transfer, with more integration aspects available. However, Informatica is an integration ETL product, and we didn't need those additional features. AWS Database Migration Service provided sufficient functionality for our database migration needs.

The cost is affordable for a six-month to one-year run period when mostly using the service.

We considered private cloud and migration into AWS accounts, specifically from private to AWS.

I work as a solution architect. For references or questions, I would need to confirm with my organization before providing direct references. The overall rating for AWS Database Migration Service is 8 out of 10.

I work for a company that was in the process of migrating a couple hundred servers to the cloud from on-premises. This is where we used the AWS Database Migration Service.

One valuable feature of AWS Database Migration Service is change data capture (CDC). You can copy the database at first without impacting your current database, and then use CDC to copy incremental changes. The switchover is also very convenient when you switch over from the current database to the new one. This helps save time because you do not need to buy servers, and AWS recommends target server configurations. This eliminates the typical low-level technical work like setting up the server and networking, which helps significantly.

I do not get involved in the day-to-day, hands-on services. So, those types of individuals would be more knowledgeable or aware of errors to answer these types of questions. Sometimes, those who implement the service face problems and resolve it, but I may not even know what problems they faced. I just see the outcome.

I have been using AWS products for nearly ten years.

I just know that it is scalable, but I do not have very intimate exposure to these services. So, the questions you are asking me will be better answered by someone who is a data engineer or who actually does it on a day-to-day basis.

I have dealt with AWS customer service. When working with AWS GovCloud, we often did not get an answer in time because AWS seemed more focused on the commercial side. However, with regular technical service, AWS is pretty good, and the support is more adequate.

Neutral

We don't use X-ray. We use some other third-party product.

I will not be able to say how easy or difficult it is to set up because I do not directly set up. However, it often takes about a week to deploy because the organization has standardized processes. They create POCs to prove it out and document the steps, which then become standardized for subsequent migrations.

Data engineers or platform engineers are involved in the deployment. Additionally, around five or six people, including security folks, are involved in this process to ensure everything is secured. Additionally, testers ensure that the database migration happens properly.

Overall, I would rate the AWS Database Migration Service a seven, without knowing much. I do not have day-to-day experience with this service. It helps manage migration work, and AWS Professional Services were a partner in the project. We used another service provided by AWS, which I do not remember the name, but it is a layer on top of the database and server migration services. It helps manage the migration work. Again, the questions you are asking me are better answered by a data engineer who deals with it daily. As for the normal AWS service, excluding GovCloud, I would rate it an eight.

I have used it for anything analytical, assisting in making the data available as quickly as possible from upstream systems to the downstream system.

We have the ability to bring data for all tables of a database in one go, as long as the tables follow a particular naming convention. I can use wild characters to bring all of those tables in one go rather than maintaining a series of table names. 

Additionally, I am using AWS for our daily lifecycle, providing ease of doing things. AWS offers a way to build jobs that are scalable, expandable for new and current tables, and can be deployed quickly. This efficient workflow has been particularly helpful.

I was looking for some content as part of a comparison analysis. However, one of the pain points is that it is way too free-flowing. I have to skim through all the security pages to get to the crux of it. 

I was looking for a table that suggests which facets such services address with proofs of reference from professional conferences. The document is a 63-page read, making it very difficult to navigate without a summary. I was looking for a summary at the start, however, if I have to do it myself, I might as well integrate from AWS Docs and then Informative Exchange. The current document contains a lot of information, which is great, but there needs to be a summary indicating the story's essence. Unless there's a correction, it is not present in the document.

I have used the solution for more than 18 months.

It is pretty scalable, requiring upfront identification of preferences. If I already know my scaling requirements, then identifying and creating the necessary insights is possible but not truly scalable. 

Scalable is usually a generic keyword. AWS's scalable nature involves a human approach, meaning it is not auto-scalable. The DMS Serverless has only recently become available. Manual scaling is feasible if I identify a higher instance to scale to.

This solution has a feature that allows me to bring data for all tables of a database in one go, given they follow a particular naming convention. Wild characters can be used to combine these tables rather than maintaining a list of table names. 

Another aspect to consider is the licensing cost. There is no licensing cost for DMS. 

I would rate the product nine out of ten.

We are setting up CDT jobs to get database changes from AWS RDS. We are not really migrating anything, but we get the changes from our source RDS instance and save it as a file in an S3 bucket.

For our continuity planning, we need all the history happening in the source database because AWS source database does not store history there. By capturing all the changes from our AWS instance and storing it in an S3 bucket, we can do whatever transformation we want without the fear of losing data. The confidence it gives us is ensuring we have the data. As long as we don’t delete these data, we always have this historical database.

The most valuable feature is its ability to get all the changes in our data and store that in an S3 bucket. This is very helpful.

Sometimes we encounter errors, and the error messages from DMS are very ambiguous and sometimes misleading. For example, if we connect to an incorrect instance with incorrect setups, it will not say the connection failed. Instead, it says the DMS task failed with an unclear error message like 'subtask AWS failed', which does not help. The connection should fail if we are connecting to the wrong instance, but the endpoint connection still succeeds.

We have been using AWS Database Migration Service for over three years now.

The DMS cannot handle the source failover or the source RDS maintenance. If the source RDS is shut down, the DMS task will fail, and we need to manually resume it, which is an issue.

DMS can handle scale very well. We went from having only two to three tasks to twenty-three tasks, each running daily every five minutes. Tasks with both large and limited data volumes work fine. From a scalability perspective, we are satisfied.

We did not open any support tickets, so we are not sure about their support. Also, we didn’t know where to reach out for support. However, their customer service is okay for general inquiries but cannot resolve some specific issues like the RDS maintenance window problem.

Positive

We were always using AWS and didn't have experience using Azure in this scenario. For on-premises Microsoft databases, DMS is more convenient and easier to set up.

The initial setup is straightforward, but we are not doing it from the console itself. We use Terraform IEC to deploy it as infrastructure as code. From an infrastructure perspective, it is slightly complicated, but this is more due to Terraform.

Every developer can handle the deployment using the IEC. It typically requires only one engineer.

Without DMS, we cannot achieve the majority of our features. Investing in this is very worthwhile.

We do not have specific pricing measured for DMS. Overall, the pricing of AWS is acceptable and not very expensive.

We started with DMS and continued using it. We did not explore other solutions.

On a scale of five, I would rate the recommendation level at four. Overall, I would rate the solution at eight out of ten.

We use AWS Database Migration Service to integrate data using Change Data Capture (CDC) functionality. Instead of directly accessing the database, we monitor the database log files for any data changes, adhering to the CDC concept. This approach ensures real-time data synchronization without impacting the production database or data files themselves. It allows us to maintain a live, up-to-date integration with AWS and update dashboards accordingly.

One of the features I find most valuable is its ability to apply rules and transformations to data during real-time integration. This includes changing schema names or table structures on AWS without delaying the data flow. Initially, full migrations can vary widely in time depending on the source system; for instance, a large Magento database might take up to six months, while smaller databases like IBM DB2 could migrate within hours. Once set up, AWS DMS ensures real-time synchronization using Change Data Capture (CDC), maintaining data integrity throughout the process.

In my experience, AWS Database Migration Service performs well for its primary purpose of data migration. One area that could be improved is its support for non-AWS file formats, particularly when integrating data from sources stored outside of AWS. For example, handling AWS Data Lakes, Delta Lake, or Hadoop file formats stored in S3 requires extensive configuration and isn't always straightforward. It would be beneficial to streamline this process to ensure smoother migrations from non-AWS environments to AWS. As for additional functionality, I think enhancing support for these external file formats and simplifying configuration steps would be valuable improvements for the service.

I have been using AWS Database Migration Service for the past one year.

Scalability-wise, I would rate AWS DMS an eight out of ten for its ability to scale effectively.

Regarding customer support, I find that receiving responses sometimes involves multiple exchanges to get adequate solutions. It can be more efficient if they provide multiple suggestions upfront in their initial replies.

Overall, my experience with AWS DMS setup and operation in a cloud environment has been positive and straightforward. I recommend AWS DMS primarily for enterprises, although it can be used by any company that leverages AWS databases. I haven't integrated DMS with AI tools personally, but theoretically, it supports data layer integration well for running AI algorithms on migrated data.

I'd rate AWS DMS a nine out of ten for its efficiency in data migration and replication tasks and definitely recommend AWS DMS for users needing robust data migration capabilities within AWS environments.

We used the solution for live replication but faced many access challenges. We moved to make a full copy and then use column-level filtering to achieve incremental load. Over time, we get the necessary access permissions, allowing us to switch to live replication. We experienced a delay of roughly two minutes, which was not an issue for our use case.

When AWS Database Migration Service started working correctly, we had approximately 300 tables replicating from Oracle and other databases into AWS S3. Subsequently, any changes, such as full replication or percentage increments, could be easily accomplished by executing additional DMS tasks. DMS was configurable and straightforward to use. They were also scaling the scheduling of DMS drops. There are so many different options available.

We use an airflow instance on AWS to scale and schedule DMS tasks. This has allowed us to retire nearly 350 Informatica or injection jobs and consolidate them into DMS, a cost-effective service.

The most valuable feature is live replication at the cheapest price. GoldenGate also has a live application, but it is probably three times more costlier than what AWS provide.

We do some processes where we use JSON coding. It could be more user-friendly, like a drag-and-drop interface or studio-like experience. Additionally, It offers vertical and horizontal scaling mechanisms. There were some issues, particularly when the migration process was extended longer. The live duplication has a delay of two minutes, which can be an issue.

AWS have some languages to pass some parameters in configurations. When running a pipeline, batch or warehouse application, we pass many different parameters like configurations.

I have been using AWS Database Migration Service for three years.

There are some stability issues If it is a high data volume. Once the initial thing is sorted out, it's stable. The live application is stable, but when dealing with billions of records. We are trying to copy the data of billions of records from the source into the destination.

I rate the solution's stability a nine out of ten.

The solution’s scalability is good.

I rate the solution’s scalability a seven out of ten.

Technical support is great.

Positive

We have Kafka, Informatica, and Snowflake in our data pipeline. Sometimes, it's just a PySpark application running from Hadoop clusters or similar setups. Using a JDBC connection, this application connects to the source database, such as Oracle or another source.

We switched to AWS because it offers better infrastructure maintainability. Another advantage is that it utilizes behind-the-scenes MPP processing, providing all the benefits of a Spark application. So, to add or remove tables from the ingestion process, you make changes in the AWS console, and the PySpark application automatically adapts. With PieSpot, we had to maintain the infrastructure and manually deploy code updates. This involved several additional steps.

The initial setup is very straightforward. As long as you have the endpoints and the specifics from the source, it's a very simple thing to do.

We retired the need for an Informatica PowerCenter ingestion server, which saved us an estimated $100,000 to $150,000 per year in hardware and maintenance costs.

The product is cheaper than all platforms, excluding Spark. Adding the maintenance costs of all the servers and everything, Spark will be higher.

All of these options were previously available. For Informatica, you would need a separate Informatica cluster. Any application that requires DNS is serverless, so you don't need to worry about managing infrastructure. You can create a DNS service and start using it.

It could be a starting point for you, and if someone wants to use Oracle GoldenGate or another service, they need to purchase infrastructure. With AWS DMS, it's a matter of creating an account and starting from there. If you want to start, you could probably decide in the morning and by evening, you would have a DMS running on your AWS account.

Overall, I rate the solution a seven out of ten.

Currently, in our company, we use the product as a part of our strategy since we recently got involved in the area of migration.

I use AWS Database Migration Service in my company for whatever applications are developed on an on-premises infrastructure since such applications have fewer scalability features when compared to the cloud. Suppose you move the applications to the cloud. In that case, the scalability can be very high, and the number of users who are going to use the product can be controlled. AWS should develop an industry-competent product so that its users can compete with other technologies and companies.

The most valuable feature of the solution is the one I use for report generation. The security risk is very low.

From this point of view, I may not be able to tell what needs improvement. Maybe I can track something that needs to be improved.

If a user uses any of the cloud environments, then there is a need to realize that not all the cloud environments are compatible with all the other tools that are used in an environment. If you take into consideration Azure, it is mostly compatible with Microsoft products, and AWS offers the same type of layout to users, which is why it is not compatible with all kinds of environments. There are a set of complexities and challenges when a user wants to integrate AWS products with Microsoft products.

The issue is not with the compatibility of AWS with Microsoft but stems from the fact that a user may face certain challenges during the integration of both products, as it is not a straightforward process.

I have been using AWS Database Migration Service since 2023. I use the solution's latest version.

It is a good and stable solution. Stability-wise, I rate the solution an eight to nine out of ten.

It is a scalable solution. Scalability-wise, I rate the solution a nine out of ten.

Around 2,800 people in my company use the product.

From our side, my company did not deal with the product's maintenance part since Amazon's team takes care of support activities.

I rate the technical support a seven out of ten.

Neutral

My company moved from the cloud services from Azure to AWS because of Azure's licensing costs.

The solution is deployed on a private cloud.

Around 11 engineers in our company are responsible for the product's deployment phase.

My company does not face any challenges related to the current pricing model of the product.

I rate the product price a seven on a scale of one to ten, where one is a high price, and ten is a low price.

I recommend the product to those who plan to use it since it provides users with all the services that may be required in an environment.

I rate the overall tool an eight out of ten.

DMS's architecture is highly beneficial, allowing for scalable migrations of large datasets. The service's change data capture feature is precious, enabling synchronization between the old and new systems, and providing customers with real-time data visibility.

There could be enhancements in the product intelligently covering more scenarios to prevent crashes or failures. Improved dashboard capabilities for monitoring jobs and the ability to resume migrations from the last successful point instead of starting over would significantly enhance the user experience.

I have utilized Database Migration Service to migrate data from IBM DB2 to Amazon, from Oracle to PostgreSQL on RDS, and from SQL Server to AWS MySQL. 

DMS' seamless integration with other AWS services enhances its functionality and usability than other solutions. The continuous data replication feature also sets it apart, allowing for minimal downtime and real-time data synchronization during the migration.

The initial setup process is straightforward and user-friendly, provided that the operators understand the migration sizes involved.

The implementation strategy begins with assessing the size of the database to be migrated and understanding the customer's key performance indicators for success. It helps tailor the migration process to meet their expectations effectively.

Key features of DMS that are effective for large-scale migrations include the continuous data replication capability, which minimizes downtime, and support for heterogeneous database migrations. Additionally, it allows for multi-threaded processing and provides monitoring capabilities, making it easier to manage the migration process.

The monitoring capabilities are robust, providing detailed logs and metrics through CloudWatch. It allows me to track the status of migration tasks in real time, assess performance, and quickly identify and resolve any issues that arise during the migration process.

I encountered a data conversion issue related to changing time formats from UTC to a different format. By leveraging the transformation feature within DMS, I successfully converted the data to meet the customer's requirements.

I ensure that sensitive data is encrypted in transit and at rest using AWS Key Management Service (KMS). Additionally, I conduct thorough assessments of access controls and compliance requirements specific to the client's industry.

I stay updated with the latest features and enhancements related to AWS services by regularly attending webinars, participating in AWS training sessions, and following industry publications. Engaging with the AWS community through forums and conferences provides valuable insights and updates.

Overall, I rate the product a nine out of ten.

My company uses AWS Database Migration Service as a small data warehouse.

What I like about AWS Database Migration Service is that it is available on the cloud, and you don't need any admins. If you want the backup then you can store it online directly. With the product in place, users can focus on what they want to do, and there is no need to do a lot of maintenance as there are no complications that arise in the tool. It is a maintenance-free product.

I haven't faced any problems with the product till now. In general, I don't see any complications in the solution.

The names of the services need improvement since AWS doesn't indicate what the function of the product is presently. You need to read a lot to find the service that you want in the product.

I have been using AWS Database Migration Service for three years. I use the solution's latest version.

Stability-wise, I rate the solution a nine out of ten.

It is a very scalable solution. Scalability-wise, I rate the solution a ten out of ten.

Around ten people in my company who are data analyst specialists work with the product.

There are no plans to increase the number of uses of the product. My company is currently operating with the maximum number of people required to use the solution.

The technical support of AWS is very helpful.

I rate the technical support an eight out of ten.

Positive

I have experience with VMware. I no longer work with VMware since I want all the products in our company to be connected to a cloud.

The product's initial setup phase was very easy.

The solution is deployed on a private cloud.

As the product is used for multiple projects, there is no specific time that can be pointed out when it comes to the time required to deploy the product. Initially, my company started off with the product's demo phase, after which we started to use it. In the end, I didn't face any challenges when trying to upgrade the product or create new tables or procedures, as it was very smooth and easy with the tool.

At a global level, the price of the product is very good. For Egypt, the product's prices are high, making it a specific problem in one region and not globally. There are additional payments to be made towards AWS Builder ID and bandwidth. If you compare the output of the product with the prices, cost-wise, it is a nice product.

I recommend the product to those who plan to use it.

The meaning in the name of the services is not indicative of what it does. Okay. It is a challenging task to handle if something is broken. Users have to depend heavily on their AWS partners when it comes to the product. If a partner is good, then the users are happy with the services provided by the product. If the partner doesn't do a good job, then users may face sudden problems, and they may not know how to deal with such issues.

I rate the overall tool an eight out of ten.