What is your primary use case for AWS Database Migration Service?

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.

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.

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.

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

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

We utilize it for mostly heterogeneous migration when you are migrating from one RDBMS platform to another. Obviously, we can use it for homogeneous migrations as well. However, it really comes in handy when you are migrating from the same source platform to the same destination. You get a lot of other options for migration, for example, you get different types of backups. You get the option for the native replication being supported by the RDBMS engines. However, when you are migrating from one platform to another platform, which is a heterogeneous case, you need some kind of Golden Gate, CDC, and all that. DMS with heterogeneous migration is, therefore, really very handy, particularly with data transformation and migration use cases.

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.

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.

We use this solution for change data capture (CDC). Essentially turning PostgreSQL (RDS) database commits into an event source for triggering other services via an event streaming solution.

We've used the product for database migration from on-prem to AWS for an Oracle database.

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

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.

We have a database team that supports migrations to public, private, and hybrid clouds depending on the client's needs.

AWS Database Migration Service is a very useful tool for our organization. One example of how we use it is when we need to save the data to ensure we don't lose it. To eradicate this risk, we save the database where we can extract it through commands. We can do a lot of with just simple commands that will assist in accessing the data with ease. Also, we can select from the API where we will use the data connections to the API where the client can easily access the data. At the day's end, we set some data from our website and view the API connection to the ABL link to the client. They can access that data to the API and the database will give the function and connect.

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.

We don't use Data Migration Services regularly. We only use it when we need to migrate a relatively large database from on-premises to the cloud. From my point of view, it was the best option in this case.

I use AWS Database Migration Service to migrate Oracle databases and PostgreSQL databases. I work with both databases and work with different migration scenarios.

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.

We use this program to migrate from SQL to RDS, or from Oracle to RDS, or from Oracle to Aurora and so on.

We're primarily using the solution to migrate our archive and data, which we are storing in our local servers, to the cloud.

We are using the solution for a database migration.