Golive on Kinetic Cloud- databases

I was talking to someone about Kinetic Cloud today and they were discussing somebody’s implementation. The gist I got was they were going to load their data into test, then copy it from test to live.

In the past I would load configurations to live, copy live to ‘OtherDB’, load data to ‘OtherDB’, run UAT or whatever then just rinse and repeat. When golive comes around I would just backup live and point imports to live and load it in.

For cloud implementations what is the best practice for managing the DBs? What will Epicor allow you to do?

This is what I would do for cloud, as well. The backing up bit is automatic, is about the only difference. CMP will let you do your refreshes live → pilot. You cannot copy Pilot to Live from CMP (but Epicor can)

1 Like

when we migrated to the cloud, the suggested process from epicor is to first migrate a vanilla version of your database - without customizations and have you migrate customizations using solution workbench. They want you to test them and not take that step for granted, and some stuff broke as we jumped in versions.

They also migrated the database into another environment with all of our customizations.

We used Pilot and Live for this.

For the actual cutover, they migrated our on-prem live database into the cloud live environment. They prefer you migrate your customizations manually using solution workbech. By that point, you have have a few cab files to import. We combined a lot into a few cab files.

The cloud migration tool is as simple as it can be and it’s been around forever. it basically takes a very compressed sql backup and restores on their end, then runs a scripts for a few hours.

Just to add, they have a process documented and your PM will go through it all. They were flexible. We had the best PM, Carol Cobb.

3 Likes

We have three environments currently - Live, Pilot & Third. Live we’re not touching until actual go-live. We’re still fairly early in implementation, so Pilot has some config, but mostly empty as well. Third has everything.

We’re maintaining all of our data in DMT imports - these are work in progress as teams continue to flush out their data needs.

As we make progress and want a clean database, we use Solution Workbench to backup customizations, we restore Pilot to Third, then reimport Solution Workbench and all DMTs using multiple playlists.

Eventually we’ll move more config and setup data to Pilot as it becomes more solidified. There will never be any transactions in Pilot, only config and setup data (Company Config, Site Config, Part master, Customer master, etc…, but no Orders, Jobs, POs, etc…).

As we approach go-live, having tested everything in Third thoroughly, we’ll load Pilot up with everything. We’ll then copy Pilot to Live. Shortly thereafter, we’ll likely drop the Third environment.

2 Likes

There are some limitations where you may get… unique with your instances too.

For example, if you were going live on the cloud and wanted to create PowerBI Reports. Currently you can buy a read only copy of your production database for $X,000 a month or get enterprise cloud for $XX,000 a month. I can’t speak to everyone else’s X’s but for us enterprise is roughly 1/4 Million more a year than a read only copy of a production database. Since we need PowerBI Reports to work day 1, we’re using live as our environment to develop reporting and testing in. We’re using third as our pristine production (eventually) environment.

1 Like

We had a similar experience to @bderuvo

We were coming from 10.2.4 on-prem. We copied our live environment (without customizations) to live cloud.

Epicor had us do this 3 times.

The first time is just to get the environment set up, the second time was a go-live dry run, where we were hyper focused on how long every step took. This is I think mostly for scheduling purposes for actual go live, they try to get down to the hour when certain staff needs to be available for their role in the upgrade process.

This stayed vanilla during the entire upgrade process until after go live.

We uploaded our on-prem live environment (with customizations) to cloud pilot.

Cloud pilot remained the environment where I was able to see what customizations ‘just worked’ after upgrade, what needed work, and what completely s___ the bed.

Come go live on-prem was once again copied to cloud live (vanilla version) and then the customizations were solutioned over from cloud pilot to cloud live.

Glossing over all of the pre and post upgrade checklists our financial folks had to do each time, and 3rd party integrations.

2 Likes

Thank you, this sounds like a great approach.

1 Like