If convenient can someone please help me know whether we can migrate DB (Orcale to MSSQL) alongwith wM10.1 upgrade (from 9.6). Are there any known consraints? Our current requirement is that we uprade to wM10.1 from 9.6 and at the sametime migrate DB from Oracle to MSSQL. It would help if I can be pointed to any specific document on this or perhaps a few steps in general as to how it should be done.
There are no out of the box scripts to migrate between two different databases directly.
You haven’t mentioned what components are being migrated. You could have two different versions running and move assets using documented deployment procedure.
Thanks Holger and Senthil for your responses. Holger, please do execuse my delay in responding to your post sooner. I was hoping to dive some more on this before responding. Especially, on the DB migration part and whether or not SAG provides any scripts to move data between these 2 DBs.
Senthil, the components under consideration are IS, MWS, UM (replacing existing Broker) and Terracotta. You are right I haven’t yet chanced upon any scripts that claim to do this migration. At one point I thought SAG might provide one such script. Anyways, the search is on. I also found that the 2 DB also differ quite a lot in terms of language (flavours TSQL, PL\SQL), Transaction control (auto-commit, rollback) and syntax etc which means there will additional efforts in code refactoring post migration . Siince I don’t have the required DB expertise so I am not able to wrap my head around the fact that why data migration should pose a challenge when the Tables and Schema construct are same (we use DCC to create compatible set of schema/tables).
Senthil, I didn’t quite get the second part of your query “You could have two different versions running and move assets using documented deployment procedure”. If convenient, coult you please elaborate some more on this.
Existing environment: IS / MWS / Broker / Terracotta - 9.6 version. This uses Oracle.
New environment: IS / MWS / UM / Terracotta - 10.1 version. This planning to use MS SQL.
Setup a brand new environment with above required components in 10.1, which connects to MS SQL as the back end database.
Export your assets from existing environment using Deployer 10.1.
Import those builds in new environment 10.1.
This way product tables will be populated through right way of asset deployment. You are also introducing UM thus you can do some tests to get more comfortable with new components, and release. I assume you would be using Terracotta for IS cluster. Re check if you have stateful IS cluster use-cases in your environment. If not, you can setup 10.1 IS as stateless IS cluster.
Thanks Senthil and Holger, it sure does help. We are still waiting on to get access to our env. Once we have that we will try out the approach as you and Holger outlined above. For now we are just trying to see what all challenges we may face and see how best we can meet and mitigate those. X-DB migration certainly tops that list and I really appreciate these responses from our experts. Thanks again !!!
Hi Syed,
I am having the same requirement as you.We want to migrate Oracle to SQL along side wM to 10.2. Could you pls share your findings and any out of box feature available to minimize the effort
To minimize efforts the first question you need to ask is: Is this really a migration?
Migration means you have for example active running business processes that you need to keep and take over to the new system, so you need a DB concent clone + migration.
If you are lucky and this is not the case you can do this like an “upgrade” just start with an clean new 10.1 installation.
The second question is about your IS instances - do they stay on the same OS as before or does it need to change?
If that is “minimize efforts” - means the same OS you can then migrate your code and settings with the standard methods – ideally on an temporary IS installation and from there deploy directly to the new servers (runtime based deploy) or checking to an source control and build packages with ABE (repository based deploy).
Sure you have to adjust your JDBC libraries and connections from Oracle to MS SQL Connect strings.
With regards to “Data” from IS in the database it depends how you maintain Scheduled Jobs, Customer User Certificates etc. Those are stored in the DB. To manually migrate those if needed should not be much of an issue. Better is for sure a new clean setup.
Finally remains the MWS part - here again it depends if you have to migrate existing portles, stay on the same OS and keep data (e.g. User, Group and Role setups; Optimize Data etc.) or just do the version upgrade as fresh installation and apply some configurations and deploy portlets later.
UM and TSA have no relationship to your DB anyway.
This is not a DB migration, but DB conversion. DB migration always involved upgrading from a lower version of DB out of support to a newer version of same DB currently in support. The purpose of the migration activity is to upgrade the DB assets/objects in the DB to comply with the newer version standard.
I guess SAG will never provide support on DB conversion, and it is be considered as custom implementation that the implementer should work with their DBA to come out with custom script to do so. Alternatively you can also try to engage SAG PS(billable) to see if they’ve done such in their past that you can request them to help.