AWS Database Migration Service Reviews

All of our infrastructure is on Amazon, so we used AWS Database Migration Service to perform a database migration from one relational database to another within the AWS cloud. The migration was from an Oracle database to PostgreSQL database, and AWS DMS helped us transfer all the tables and other objects from the one database to the other automatically.

If your infrastructure is already on Amazon, it simply makes the most sense to use a tool officially provided by them as an additional service, rather than having to rely on a third-party solution.

On the other hand, if you have a custom infrastructure and you want to migrate to Amazon, it also makes thing much easier to integrate. The way it works is brilliant, and it's based on similar logic to Oracle's GoldenGate migration tool in that you can migrate everything from data tables to schemas from one database to another. So in most situations where you would need to migrate to Amazon, the best way is by using AWS DMS.

One area that AWS DMS can improve on is its conversion of data types. For example, in Oracle, you have a data type called RAW, but in PostgreSQL there is no such thing. Thus, AWS DMS doesn't know what type I want to use when migrating from Oracle to PostgreSQL, and when performing the migration, AWS DMS changed the RAW data type to the byte data type, which isn't what I wanted.

For example, if I wanted to manually transfer the RAW data type in the Oracle database to something else like VARCHAR in the PostgreSQL database, AWS DMS doesn't seem to have this functionality. It would be great if I could change the data type conversions manually instead of automatically.

Another area that has proven difficult for me is the use of AWS Schema Conversion Tool, which is a free, cross-platform app that they offer as part of AWS DMS. I was under the impression that I would first have to use this tool to convert from one database to another, and then use AWS DMS, but when I used it, some of the tasks didn't work correctly. To my surprise, when I skipped using the Schema Conversion Tool and went ahead with the migration with AWS DMS, it automatically transferred everything and it was all correct. So I am not sure what the point of the Schema Conversion Tool is, because the default functionality of AWS DMS seemed to transfer and convert the databases fine without it.

There is also room for improvement from a support perspective. It is sometimes necessary to contact their support team when there is something you don't understand, and when I wrote a support ticket they simply weren't able to help. Yet, when our company contacted the manager of our reseller, they were able to create a meeting room with an Amazon specialist for DMS, and with one call, all our questions were answered. I think their email support team could be much better when compared with their personal support team. 

I have used the solution only once, during a migration which took place over two or three months. 

I only used AWS DMS over the course of about three months, but I could tell that it's not always stable. I think it's fine if you only need to use it for a short time with a one-time migration, but if you intend to use it all the time in, for instance, a staging environment, every day of the month, I wouldn't say that's a good idea. I would only use it for quick migrations.

I have certainly needed the support, especially when I don't understand why something doesn't work. This is often the case when dealing with different types of databases, such as Oracle and PostgreSQL. We also use a lot of other databases, so for us, contacting support is almost inevitable.

Once, when I wrote a support ticket but I didn't get the help I needed, our company wrote to the manager of our reseller who arranged for a meeting with Amazon's personal support. We spoke with an AWS DMS specialist in this meeting and showed him our problem, and with this one call, all our questions were answered.

It's easy to set up when you use Amazon's official documentation, and the first steps are simple. Amazon also has a few practice videos so you can see how it is done.

However, it's not always easy to adapt the documentation according to our own particular applications and databases. For example, if you've never used it before, you will likely need to set aside a minimum of 40 hours for reading and testing.

I implemented it by myself.

The pricing is per hour, though I do not have the exact figures.

If you have specific questions about the service, a personal support team from Amazon is available, but this will bring in additional costs.

Our infrastructure is fully on Amazon, so for us AWS DMS was an obvious choice to perform our migration as it is an additional service that Amazon provides. To those who are thinking of using the same, I would say go ahead and try it. If you come across any problems or have questions, you will most likely need to contact Amazon support, which can give good service, but it's not ideal. The paid support, however, worked well for us.

I would rate AWS Database Migration Service a seven out of ten. 

We use this solution to get our data into Lakehouse with the CDC. So, Change Data Capture is also very important for us. AWS Database Migration Service has an inbuilt functionality for capturing change data.

The identifier of this solution informs us whether it's an insert operation, an update operation, or a delete operation. Since our main data is OLTP, the status of the order can keep changing; it can easily go from payment to successful and resend to cancel. 

This solution is very good at mini-batch processing if a user needs a latency between thirty seconds and two minutes. 

This solution can offer more tweaks where the latency can be brought down to fifteen seconds. DMS is not the go-to choice when it comes to data streaming, and the major reason is the latency issues because it's file-based and not message-based. So if DMS could offer such a solution, it has the potential to replace Kafka as well. DMS is more of a one-click setup in comparison to Kafka. 

I have been using the solution for two months. 

The solution is very stable. We haven't faced any downtimes yet. I would rate the stability a ten out of ten. 

I would rate the scalability an eight out of ten. We haven't faced any issues with scalability. As it's a background service that is actually replicating our data, DMS does not have an end user; it only turns the data into S3. When we connect to the database, that is when the end user comes into the picture. 

Our previous architecture was based on Debezium and Kafka, where Debezium was being used as a CDC tool. The learning curve for Debezium is much more steep as compared to AWS Database Migration Service. Also, with Debezium, if you are not using any external vendors, then you need to have DMS self-hosted on your own Kubernetes cluster. 

The setup process for this product is quite simple and AWS has provided very good documentation for this purpose. 

We implemented the solution in-house. 

I would rate the pricing a seven out of ten. 

I would rate the solution a seven out of ten. I would definitely recommend this product to others. 

We primarily use the solution to migrate databases. 

We have an Oracle database on-premise, and then we have a plan to install the new system with a database for another application service. Therefore, we need to duplicate, to copy, our Oracle database to the Postgres database on AWS. 

The solution makes it very simple to migrate the database. 

The solution's price is cheaper than Oracle GoldenGate or other solutions. 

We can get a lot of support services from AWS via the MSP. 

The solution is stable and reliable.

It's scalable. 

This solution is compatible with only AWS. I cannot use this solution with AWS and other cloud services like Azure or Google Cloud.

We've been using the solution for one month. 

The solution is stable. There aren't bugs or glitches. It doesn't crash or freeze. The performance is good. 

We have five customers that use the AWS Service. I don't know how many exactly use it. We have just five AWS customers in our company.

I can expand the hardware specification from one virtual machine to three or four. I can expand the hardware cloud resource without rebooting or stopping the service. This solution is scalable.

The support on offer is pretty great. 

We have only one way to get support from AWS. We need access to our support partner. We need the budget to get technical support from AWS as we need a contract with an AWS MSP partner.

Our engineer did recommend this solution first for migrating the database. We copy our Oracle database to AWS first. And then, we move our Oracle database and Postgres on AWS. I have experience with Oracle GoldenGate.

This solution is a PaaS solution. We do not need to handle an installation for this solution, as it's already installed on AWS.

We are a user of the product.

I recommend the solution. I'm pretty happy with the capabilities. 

I'd rate the solution a nine out of ten.

We looked for Oracle to Aurora conversion migrations. This has two parts, one is called the static table schema migrations, which is a one-time snapshot that we just stamp and load. The other is the CDC replications, or real-time streaming replications, heterogeneously from Oracle to Aurora. 

The solution is simple, which is key. 

AWS Database Migration Service is a huge product, and it takes a great amount of effort to reverse engineer what they do on the backend. It would be better if they did more troubleshooting at the moment. Currently, if something goes wrong, you get a message that says one thing that has nothing to do with the RCA, and it could be misleading. You aren't even sure which part was broken.

There is no connectivity to the source database or the target database. Any of those channels could break, and it becomes very hard to troubleshoot. 

I have been using AWS Database Migration Service since 2016.

The solution is stable. Typically, once the solution is up and running, and you don't change your application code, it will keep working. Even if it does break down, it will automatically recover itself and resumes from where it stopped.

The scalability of AWS Database Migration Service depends on how you define the scale. There are two considerations, one is the initial part of ETL replication. The other is the CDC part, which is after the full image replication is done. 

On the full ETL, you can scale. Meaning, even within the table you can do a parallel on the table level, or within the table level. After, you do a soft positioning for each range you want. A DMS would assign a process link up to that range, this speeds up the skip performance for the ETL.

As for the CDC, there are limitations. CDC is typically a single channel or single thread. That is because CDC is time-based and a binary transactional log. To do a parallel, you would have to do a lot of work. In our scenario, I could not use DMS. I had to use the in-house developer to do a catalog version of CDC.

My experience with Amazon's technical support depends on who I get for support. If I'm lucky to get someone with experience, the issue will be resolved right away. If I get an amateur, they will avoid answering any questions and send me tons of documents. 

Most of my questions are eventually fixed or solved. I would rate service and support a seven out of ten overall.

Neutral

In a typical deployment scenario, I set up the lead-only account on the source database. I make sure that I will not write anything to the source database to compromise the integrity of my source database. I have to write to the target database. Then the solution is ready for use.

Deployment of AWS Database Migration Service requires a POC first, then you make sure that everything is working and run it for about three weeks in an on-premise environment. Then you deploy, either manually or through the telephone, to an AWS production environment.

AWS Database Migration Service is very inexpensive. The cost is considerably lower than Agility or Oracle Golden Gate. We do not have a license for the solution. We are charged based on our usage.

We evaluated Oracle Golden Gate. They offer similar features to AWS Database Migration, but they lacked simplicity. With Golden Gate, you have to set up the entire enterprise software stack which requires so many steps.

We also looked into Aurora for replication, version eight. This product offers parallel replications of CDC, which is very useful. 

AWS Database Migration Service is most useful for a company that is trying to do partial applications for a short amount of time until the entire application is cut over from one place to another.

If you are considering AWS Database Migration as a solution for your organization, I recommend you pay attention to your CDC throughput, it is a single showstopper if you misuse it. I try to use it for our current application's traffic, which is about 30 megabytes per second. DMS would not be able to handle that in-house, it would just keep lagging.

Overall, I would rate AWS Database Migration Service a nine out of ten. It is a very useful product.

Our primary use case is that I can easily automate. I don't want many resources working on setting up a new IDE and creating an application and so on. We can make use of the existing applications in the cloud and I can do a workflow management very easily.

In selected or traditional databases on-premise, the backup and maintenance are very difficult. If you are maintaining a complete platform, like a Linux platform, you will need to apply some regular DB patches, so things are very difficult here. But in AWS RDS, there are many databases available for which the maintenance will be taken care of by the AWS team and different scalable databases also available. For example, currently we are using other database subscriptions which are very useful for my applications. Earlier we had Oracle Streams but we migrated to Aurora.

The process is now simplified because there won't be maintenance. Usually we can take a snapshot of the number I need. We can automate the backup snapshots and we can restore it very quickly. We get many benefits from the application. For example, day to day, there are developers trying to run SQL scripts which will cause problems in the database. So instead of troubleshooting, I can simply roll back to the existing set so that they can work easily. The support that I get for my project and the deadline to release one new feature will usually take three to four months on on-premise. Now, since I have migrated to AWS, I can finish it in one or two months.

There is something where AWS Database Migration can be improved. Many of the application teams don't want to invest on a migration. They don't want to use the Database Migration service. They want us to export to the dump point, database backup, and then put it into the RDS. There is not a cast and mold on it except in the database and that's it. So migrating from here and pushing the data from on-premise to AWS cloud is a big challenge, and a few more services from AWS would be helpful. For example, currently we are using ILDB internet tools which move data from on-premise to AWS cloud. I need a few more services which would be really helpful for me to move the master data.

I have been using AWS Database Migration Service for almost four years to move applications from on-premise to AWS cloud.

It is stable in terms of the data. 

It is scalable. Nothing that we execute needs to be touched in the database. They simply do the code only. So whatever changes we do in the database will be tracked.

If you raise an AWS support issue you will get an immediate response from them so I can resolve my issue as early as possible. That is a good thing. That is why I am likely to take the support from AWS and enable the service very quickly. They have good experts who are available. That has been my experience.  Let's take an example from IBM technical support. I raised a case related to the IBM One Sheet. I'm following up now for one week and they are not responding properly.

I have not explored other solutions like GCP or Azure, but I have used the AWS side. On a scale of one to ten, I would give AWS Database Migration a seven. 

This score is because of a few difficulties I faced when setting it up. Because I worked on different applications on a couple of projects, I cannot completely make use of the AWS database. Maybe that is a developer mistake or something. That's the reason I am rating it a seven for now.

We have taken that as a Platform as a Service. So, how we are running here, we just migrated whatever database instance in the rack was there to AWS. It was an "as-it-is" migration. 

For data, we tried to use SSIS to transfer the data from the patch to AWS.

The main thing why people are going behind AWS is the cost. 

For example, on the current project, I am working with an insurance company. So the basic thing is they want to accomplish whatever add-on services AWS provides, but they don't want to go all in a single step. Plus, they want to see what the platform is. Then they look step by step. So, it is an incremental adoption kind of thing.

So, we are helping and enhancing our knowledge of that.  

As a solution, the better thing is if more platforms come with direct compatibility, like connecting to different data sources. 

The basic problem I faced the most was while transferring and reading data from Excel. So, one time, I found that all the components I had declared in my scripts were able to take it. 

And after some patching happens, it is not able to support that. Again, we need to update the version of Excel. So, it's not like a plug-in type place where you have done the solution and are confident that it will work. So, this is an area of improvement. 

If we look at Microsoft products, most things look or are plug-and-play. For example, if you are using storage as a service, we need to go for CLI commands. So, those types of stuff that's not as easy as using a Microsoft product, like DDoS, that level of easiness is not there.

In the project I am in, we migrated from SQL Server from RAS to AWS recently.

I would rate the stability a six out of ten. We had some issues with stability.

I would rate the scalability an eight out of ten. It is able to scale up and fulfill requirements. 

The only thing weakness is compatibility. Like, once you program and forget it, it's not that type of thing. 

I faced some problems while patching; new things come up, and sometimes old things don't support, causing a bit of a headache for me. 

We have a big-sized company with various clients. 

Experience with customers and support was good. I got a good response. It was not a delayed response, or it was not that I had to go back to the multiple times for the issue. It was not there. 

Overall, I had a good experience with the support.

The initial setup is simple. Not that much complex.

The pricing is neither high nor low. It is value for money. Moreover, the facilities or the add-ons they give are good.

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

What I find most valuable in AWS Database Migration Service are these features: the full load and continuous data replication to heterogeneous endpoints.

There's a lot of room for improvement in AWS Database Migration Service, e.g. more endpoints to be supported, more control and transparency on the product and on how we get things done, and better operational support.

I've been working with AWS Database Migration Service for two years.

The solution is stable, but we have migrated a lot of those data sets to Qlik Attunity. I also worked for Qlik Attunity for consulting and database DMS.

AWS Database Migration Service is scalable, but Qlik Attunity is more scalable.

The technical support for AWS Database Migration Service is bad. They are still figuring out how to support their product. I've reached out to some AWS resources, but they don't understand the support.

The initial setup for the solution was moderate. It had some learning curve, but it was moderate. It was okay, and it was not difficult to learn.

How reasonable the pricing for AWS Database Migration Service would be, depends on where we are getting this data migrated from. Pricing for the solution is reasonable, but it could still be reduced.

I evaluated Qlik Attunity.

I use a lot of Qlik Attunity and AWS Database Migration Service.

I'm more of a consultant/engineer, so I use Database Migration Services to move data across different instances from on-premises to AWS, etc.

My advice to people who want to implement the solution is that there are alternate products. AWS Database Migration Service is still a good start, but an alternate product such as Qlik Attunity does a very good job, e.g. Attunity gives you more control.

I'm giving AWS Database Migration Service a six out of ten rating.

We are moving everything to the cloud and we need a migration service to migrate our on-premise data warehouse to the cloud and this is what we use AWS Database Migration Service for.

The most valuable feature of AWS Database Migration Service is it catches all the history changes, such as inset, observe, and delete. It tracks everything.

I have been using AWS Database Migration Service for approximately two months.

AWS Database Migration Service is stable.

I rate the stability of AWS Database Migration Service a four out of five.

We have approximately a team of 30 of our intelligence team using the solution. This includes system and database administrators.

I have not needed to use the support from AWS Database Migration Service.

The initial setup can be difficult for beginners in AWS Database Migration Service. You will need the training to complete it.

We still need to maintain our on-premise operation and maintain the service as we migrate to the cloud. We have a team of two to five that are maintaining the solution.

My advice to others is for them to take the training first. If you don't take the training, it's a bit difficult to understand how it works.

I rate AWS Database Migration Service a seven out of ten.