Is there a way to transfer settings from the Test Environment into Production?

We are going live maybe in January and I have TON’s of work setting up our test environment to be perfect, or close to perfect at least and I would like to know if there is a way to move all those changes and customization’s from one environment to another.

I would hate to have to recreate everything one by one, but if it needs to be done, it needs to be done. Thank you in advance.

We are in Epicor 10.2.600.3

1 Like

Solutions workbench build out the configurations into a cab file that you can import into your production environment.

2 Likes

wow, cool thank you. I was thinking it would be in the individual windows. I will look into this and get bac to you, thank you.

1 Like

I’d second what @Aaron_Moreng suggested. The solution workbench will do the job.

2 Likes

Don’t worry. You’ll get good at it anyway.

3 Likes

Looks like it is a bit involved, doing a presentation on Epicor tomorrow, so I need to prepare for that, but I will look into this more in depth next week, thanks so much.

hahahha, I kind of feared that

So true…

2 Likes

I have not done it just yet, I have been messing around with GL, but using Solutions Workbench, can i export certain sections, not all of them?

Our GL is 100% perfect in production, in test,… its test and not the best so I want to make sure I export only what I feel is perfect from Test into Production, rather than the entire environment.

I haven’t moved an entire GL myself, but I would assume that all of the structures necessary for this exist in the solution workbench. I could poke around if you give me some guidance on what portions you’re having trouble locating

no no, I got everything (I think) I needed done in the GL. i want to export certain parts of the Test environment, into the Production environment, not any of the GL stuff though. I need to make sure when I export from test and import to production, nothing on the production sides GL is touched.

If it were me, I’d do a test on a copy of production to get the gist of moving things with the SW to make sure you’re comfortable with the results

I will try it in from Test into Pilot, but actually, I am thinking maybe I should export Production as well, just to have a current backup of its current state, just in case something happens. Thanks buddy, I will report back after I have tested.

1 Like

Can’t be too careful :wink:

Ok, I just opened the workbench… and I feel stupid… and am thinking maybe the easiest way would be to just build the production environment from the ground up. I basically want to copy test into Production, without touch the GL, I may need to read up some on the solutions workbench. You are all recommending it, so it must be good but i feel very overwhelmed by it.

nah, you don’t need to be overwhelmed by it! It is not a great UI, but basically you are going to select the pieces of the puzzle you want to bring over, pack those into a “solution” and then apply that solution to the new environment.
I think in your case, you’re going to be moving the ZDataTable elements related to the GL tables, which contains the configuration. Try it out with moving a known config first and then apply it to a test environment

but what I want to do, is bring over all the work I did in test, over to production but it may be best to bring it into pilot first to make sure it works. There are no real customization, just all the groups, operations, project entry templates, all the work I have done in this environment from the last 3 years, building it up to 100% work over to our Production (pilot first) and make sure it works. I do not want to bring over GL, GL is perfect in production, just everything else from test into production

This is the right way to do that then. It doesn’t bring over the data per se, it brings over the config

ok cool, I will try it… is there anything I should look out for to not bring over the GL? I am trying to be so careful NOT to touch the GL.

Your best tactic here is to try it out before doing it, so pack it up from the “good” environment and apply it to a test environment and make sure it did it right. Any, taking backups of the environment before you start, etc. Think of it as a practice round