AWS Database Migration Service Reviews

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 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.

We're currently moving our whole database from AWS to Oracle. We want to avoid interrupting production systems, so we're using DMS to continuously replicate data from the AWS RDS database to the Oracle database in OCI. Once we're sure all data is consistent, we'll switch over to Oracle and shut down the AWS database.

This should minimize downtime to about 15 minutes, and all our services in AWS then point to the Oracle database.

For our simple requirement of migration, DMS is just a typical AWS RDS with an IPSec tunnel to Oracle. The most valuable features for us are the networking capabilities like VPCs and VPNs.

Currently, we're happy with DMS because it's simple and meets our needs. We're still syncing the data, but once that's done, we'll cut off the AWS database. Compared to Oracle GoldenGate, DMS is definitely easier to use. We haven't encountered any major difficulties.

The cost is a concern. We use DMS because of its simplicity, but the price could definitely be more competitive.

So, in my opinion, some potential areas for improvement are price and possibly supporting Oracle Autonomous Database (ADB) on AWS, as it's a powerful option.

Oracle ADB on AWS would significantly reduce our migration workload. Price and lack of ADB support are the main downsides of DMS for us right now. In fact, about 60% of our monthly AWS costs go towards database services.

We've been using DMS for a while to replicate databases between AWS and Oracle, mainly for backups and test environments.

I would rate the stability a six out of ten. It took us a while to get it running smoothly. It wasn't entirely straightforward. But once it was set up, it was stable. AWS support was helpful during the initial setup.

We haven't encountered any scalability issues so far. We might need to increase the database size later, but it's not a problem. So, I would rate it an eight out of ten.

We actually bumped up our support level for extra coverage, and they've been very helpful. We also have AWS expertise on our team, so there haven't been many difficulties. Overall, the support is good.

The biggest challenge we faced was setting up the IPSec tunnel between the two private networks. It took a while to figure out why they weren't communicating even though the tunnel was up. Luckily, our AWS networking experts managed to fix the routing issue.

Neutral

Currently, we're moving from AWS to Oracle. We're migrating our database, and that's already been taken care of. The issue with AWS has been addressed, and we no longer have any problems with it.

We're new to DMS. We decided to use it about three months ago. That's why we compared DMS with GoldenGate to choose the best option for migrating our database. 

The setup process was simple enough for us because our database is plain and doesn't have many blocks. It's just a typical cloud-based product, like most AWS services.

We use the enterprise and the AWS license, which is a bit expensive. We're consolidating our databases from AWS to Oracle, which we find more cost-effective. So, we're using an autonomous database in Oracle, a feature not offered by AWS.

We've been using AWS for a long time, including for non-Oracle services, and overall, we're very happy. It's much better than GoldenGate, which was a headache for us. 

Overall, I would rate the solution an eight out of ten. 

We use this solution to enable us to carry out heavy, data-level migrations across multiple ETL tools.

We particularly like that this solution has the facility to integrate with all ETL tools.

We also like that this solution provides us with high speed velocity, performance, scalability, and throughput for our data migration tasks.

We would like to see some improvement in the performance of large scale procedures, such as when we migrate from Oracle to csSQL.

We have been working with this solution for over five years.

We would rate this solution a 10 out of 10.

I'm using AWS Database Migration Service for migrating data from an on-premise Oracle database to a database on AWS.

What I like about AWS Database Migration Service is that it's a good product that allows you to migrate terabytes of data. My team was able to migrate almost 16TB of data using AWS Database Migration Service. The solution works fine for my use case.

What needs improvement in AWS Database Migration Service is that it lacks a log file validation feature. If the solution could provide more details about a particular transaction, that would be helpful.

The stability of AWS Database Migration Service for online CDC records also needs to be improved.

I've been using AWS Database Migration Service for more than six months now.

AWS Database Migration Service is not as stable for large volumes of data, especially when you process CDC records daily.

AWS Database Migration Service is a scalable solution.

In terms of the technical support provided for AWS Database Migration Service, seventy percent of the team is knowledgeable, and the remaining thirty percent isn't as knowledgeable.

Sometimes, the response from support is very slow, and for every question, you'll get the same kind of answers. The technical support team should analyze the errors properly, especially with production and queue errors because I don't see that happening currently.

AWS Database Migration Service has a straightforward setup. On a scale of one to five, I'm rating the initial setup four out of five.

I'm not aware of the pricing for AWS Database Migration Service.

AWS Database Migration Service has two users within my company. It's me and another person, though that other person doesn't use the solution as much. I only use AWS Database Migration Service whenever data migration is required.

I'm rating AWS Database Migration Service eight out of ten.

My company has a partnership with AWS Database Migration Service.

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.

The tool is offered as part of AWS stacks. We use it for data migrations from on-premise to AWS stack via PostgreSQL and MySQL. We also use it for the infrastructure configuration to simplify the setup because we are going on RDS. The AWS platform will manage everything. We use it for the simplification of migration. We do not do a lot of study on how exactly to map the database provisioning.

The database migration services allow us to do real-time synchronization of on-premise and database to plan out our releases. We do prod testing to keep the prod data in sync, at the same time, not expose it much. The automation of this synchronization helps us ensure the data is consistent in both AWS and on-prem. Then we can switch over wherever you need it. Parallely, we can do production performance testing and user experience testing without actually writing a lot of code. It comes out of the box. It is one feature that we like a lot.

The other feature I like is schema migration. When we want to upgrade it to MySQL, we can easily upgrade it. It is another stack. We haven’t used database migration. We can use it if we want to move from Oracle to PostgreSQL. It also comes as an out-of-the-box solution. I think these three things are very good. However, we have not used database migration yet because we do not plan to install software yet. The solution has a good feature stack.

The product's performance could be a little bit better. It is good in terms of the data, but it is difficult for the first time. After that, the synchronization is fine. We saw a few failures because of the bandwidth the first time the data got loaded. The performance could be better, but it's only for the first time. We haven't seen any performance-related issues post the initial setup.

I am using the solution right now.

There's no issue with stability. The solution is quite stable. It has to be stable. The only reason we are moving to AWS is to be scalable and perform well.

On-premises scalability is the reason why we are moving into AWS. The product's purpose is to introduce scalability. We would not have picked it up if it was not a ten out of ten. It is expected to be scalable because of how the nodes are getting set up in AWS. We have a medium to large user group. It's for a finance-related project. So there are quite a bit of end users, but not very high. It is targeted at brokers and stock traders.

The technical support is really good. We have partnered with Amazon, and we are part of Amazon's consultation team. There's a service engineer and an overall account manager who take care of the issues. For any automation issues, we can go through them to coordinate. They provide excellent support.

Positive

The initial setup is quite easy. The product has one of the easiest installation setups.

My team, who has expertise in Data Migration Services, did the implementation in a few hours. We have five DevOps team members, two architects, one for data and one for infra and application, and managers. The development team varies. It depends on the system. The rest is the core team. Below the core team, we usually have pilot teams and project teams. We might have a specific development team if a feature enhancement needs to happen, but it is very rare. The core team comprises five DevOps, two architects, and one manager. The maintenance team takes over the maintenance of the on-premise system.

I recommend using the solution if the end goal is AWS. It should not be used for GCPRs and on-premise migration. A lot of the features are applied while the migration tool is in place. The migration tools, like data and schema migration tools, make more sense if the target infrastructure is AWS. You could not use it as a separate tool. If someone is looking at an AWS infrastructure, they have to use the product. However, if they are not looking at AWS and want to use it as a tool, they should not use it. For such cases, they can use the available free and open-source versions of the tools.

Whatever features are there in my system are all available in the solution. Out-of-box migration is also available. I don't see anything that is missing. My system is a real-time system. For me, it's a relational database with straightforward data structures. The volume is much higher if someone has big data processing migration, which may be a problem. For any big data solution, they will have to rework it. The product will not support it. When you have properly structured data, it is not that difficult for AWS to make it. I don't know how effective it will be if you have unstructured data, like big data and unstructured datasets. I have not seen a lot of use cases.

Overall, I rate the product an eight out of ten.