Good afternoon,
We currently have running in AWS a SharePoint 2013 farm with a SQL database back end. Works great. Does what we want.
I do have some questions and hopefully get a few ideas here on how to maybe make it better.
Currently we have an A deployment which is production a B which is a backup and a staging server, where we put new deployments on to test.
Usually how this works when we get a new deployment, we take A database and manually migrate it to B and Stage.
The reason is, my customer wants the ability to automatically go back to a working copy if things go awry and the SP deployment goes wrong.
I can’t think of a way to automate this process either through SQL or through AWS without a way of doing a manual database migration. What we have works, but it’s time consuming and very clunky, and doesn’t seem to be best practices.
Can someone possibly give me some ideas that I’m not seeing?
Are you talking about the SQL DB that hosts all of the SharePoint content (content db)? Or, is this a completely custom database? There are few tools from the likes of Redgate, AvePoint, Sharegate, Metalogix etc.
Another thing to mention, the databases are currently single threaded in a single AZ. I’d like to leverage some of the features of redundancy and high availability available in AWS while still meeting the customer requirement of being able to immediately have a hot standby. I was thrown into a product already developed and I come from a primarily Oracle background.