There were some hiccups during the database migration in terms of schema migrations, in particular, there were some technical limitations, though I'm not able to fully recall. Apart from that, AWS Server Migration Service was okay. Because of the technical limitations, we had to change our migration strategy and had to do some convergence before we can do the migrations. We had to look into work-arounds, and that resulted into delays, but for 90% of the databases, we were able to do the migrations using the native methods. If the database schema conversion could be made more seamless for AWS Server Migration Service, it would help. There were also some elements that were not built-in for database migration, so if they can widen the scope of those features, that could make this solution better.
![AWS Server Migration Service [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_100/ecwtjjlwilx2g4qujp0d5nz7cwsn.jpg)
![Carbonite Migrate vs AWS Server Migration Service [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_30/durwsc3z47nd2vx5dltpkmpv49gk.jpg){kind=small}
![AWS Application Migration Service vs AWS Server Migration Service [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_30/ecwtjjlwilx2g4qujp0d5nz7cwsn.jpg){kind=small}
![Nutanix Move vs AWS Server Migration Service [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_30/haosg86qw426gprr0w60eovzmyaw.png){kind=small}
