Migrate to new domain- new code- old db

[Mark]

I have a fresh installation of TB that I want to use with an old db.

The working installation I have has always had things wrong (ie blog not working) so I do not want the old code base.

Im shifting domains completely, with a fresh code base. But I do want my old database.

Whats the suggestion here?

Edited March 17, 2020 by Mark

[Acer]

Not sure what the guys will recommend. But while we wait, maybe you can try the following just for fun?

• Make a clone of the existing, broken site on your local environment and check that the copied site runs
• Using the copy of the site, delete the modules that are not working - either using Admin or if this doesn't work, delete the actual module folder under modules
• Use Core Updater and update the site to latest version or bleeding edge if you must
• In theory, it should detect the missing modules + add them back in
• Resulting in old db + new code base and working components / modules (Blog etc) 

Let us know how it goes

[wakabayashi]

Why can't you just import your database backup into the new database?

But TBH, if you have no expierence at all with such actions, I would hire somebody.

[Traumflug]

Chances are good one imports this trouble by importing the old database. Starting from scratch with an old database doesn't make much sense.

To clean an existing installation:

• Uninstall and delete all non-thirty-bees-modules,
• delete all overrides, which means, all files ending in .php in overrides/, except index.php,
• Use Core Updater to update the installation to have no obsolete and no modified files.

To move from one domain to another, move/copy all files and move/copy the database. This should give a working back office. To move front office as well, adjust the domain URL in Preferences -> SEO & URLs, third panel from the top.

 

[Sigi]

just to understand it correctly:

1. adjust all the settings in the back office i need. (in new tb installation with new url)
2. install all modules i need and configure them (in new tb installation with new url)
3. export my articels from existing shop (e.g. with datakick module)
4. import my articesl in new shop (in new tb installation and new url) with csv.import
5. export the needed database files from existing shop(customers, carts, orders(history), adresses, categories, contacts)
6. adjust the exported database files to the new shop (e.g. with notepad++)
7. backup and then delete the database files from the new shop which I want to replace
8. import the adjusted database files to new shop
9. everything should work?

 

please correct me if there is something wrong or missing!

The difficult part for me is 5. and 6. 

At point 5. there are many files e.g. at customers, customer_group, customer_message, etc... wich are the relevant ones, when i want to keep all the data about my customers and their orders, to know wich articel was orderd how often? (maybe i should know this for myself, but it is difiicult...)

At Point 6.: what do i need to adjust? In my old/existing shop, it was a migration from ps1.6 so when i compare the file with a new tb file i see that there are more differences than just the host, server-version and database-name. 

In the files I see that often in "create table" there are differences (see picture). Do i need to adjust this too or is this not necessary? Or what explicit is necessary to do?

 

Would be great if somebody could tell me if I am completly on the wrong track...

 

edit: existing/old shop is tb-version 1.1.0

new shop on new url is: 1.1.x bleeding edge

On 3/17/2020 at 11:59 AM, Traumflug said:

To move from one domain to another, move/copy all files and move/copy the database. This should give a working back office.

Edited March 23, 2020 by Sigi

[Mark]

I tried as above what Sigi suggested, using getdatakick from @datakick however datakick advises me that it was not the intention of his module to do this and I've found it doesnt work exporting TB then importing via his module.

On 3/20/2020 at 9:18 PM, datakick said:

My tool is not intended to import db dumps. It's a generic import solution for generic xml files --> usually product feeds provided by your suppliers

Edited March 26, 2020 by Mark

[x97wehner]

There is a migration tool I used a couple years ago that did this very well when coming from prestashop. Its called MigrationPro. It moves all the core data pretty seamlessly.

[Mark]

Ive tried @Theo's idea. @wakabayashi's idea @x97wehner's idea @Sigi's idea @Traumflug's idea.

Thank you all for your help:

Theo's idea: Feedback below:

On 3/17/2020 at 8:56 PM, Theo said:

Not sure what the guys will recommend. But while we wait, maybe you can try the following just for fun?

• Make a clone of the existing, broken site on your local environment and check that the copied site runs
• Using the copy of the site, delete the modules that are not working - either using Admin or if this doesn't work, delete the actual module folder under modules
  • All non TB modules were removed
• Use Core Updater and update the site to latest version or bleeding edge if you must
  • Am running latest updates on Bleeding Edge
• In theory, it should detect the missing modules + add them back in
  • Didnt happen
• Resulting in old db + new code base and working components / modules (Blog etc) 
  • Fail

 

On 3/17/2020 at 10:30 PM, wakabayashi said:

Why can't you just import your database backup into the new database?

• I did start this, obviously all the table name prefixes are different though

But TBH, if you have no expierence at all with such actions, I would hire somebody.

• I do have experience with this and common sense. I should not have to hire anyone to shift domains.

 

On 3/28/2020 at 2:03 AM, x97wehner said:

There is a migration tool I used a couple years ago that did this very well when coming from prestashop. Its called MigrationPro. It moves all the core data pretty seamlessly.

Could well be great, but shouldnt have to buy this module to undertake this function.

 

On 3/24/2020 at 8:52 AM, Sigi said:

just to understand it correctly:

1. adjust all the settings in the back office i need. (in new tb installation with new url)
2. install all modules i need and configure them (in new tb installation with new url)
3. export my articels from existing shop (e.g. with datakick module)
4. import my articesl in new shop (in new tb installation and new url) with csv.import
5. export the needed database files from existing shop(customers, carts, orders(history), adresses, categories, contacts)
6. adjust the exported database files to the new shop (e.g. with notepad++)
7. backup and then delete the database files from the new shop which I want to replace
8. import the adjusted database files to new shop
9. everything should work?

 

please correct me if there is something wrong or missing!

The difficult part for me is 5. and 6. 

At point 5. there are many files e.g. at customers, customer_group, customer_message, etc... wich are the relevant ones, when i want to keep all the data about my customers and their orders, to know wich articel was orderd how often? (maybe i should know this for myself, but it is difiicult...)

At Point 6.: what do i need to adjust? In my old/existing shop, it was a migration from ps1.6 so when i compare the file with a new tb file i see that there are more differences than just the host, server-version and database-name. 

In the files I see that often in "create table" there are differences (see picture). Do i need to adjust this too or is this not necessary? Or what explicit is necessary to do?

 

Would be great if somebody could tell me if I am completly on the wrong track...

 

edit: existing/old shop is tb-version 1.1.0

new shop on new url is: 1.1.x bleeding edge

Could not get Datakick's module to work

[datakick]

1 hour ago, Mark said:

Why can't you just import your database backup into the new database?

• I did start this, obviously all the table name prefixes are different though

But TBH, if you have no expierence at all with such actions, I would hire somebody.

• I do have experience with this and common sense. I should not have to hire anyone to shift domains.

This was always the way to go. Ever since the first version of prestashop, this is how you move from one domain to another. There are thousands of tutorials on the interned describing the process.

In short:

1. backup database
2. copy all files from source to target server
3. extract db dump
4. adjust configuration (db connection, cache servers, server urls)

This will, of course, keep the original table prefix. But who cares if tables starts with ps_ or tb_ or ps_db_34fslj, it's just prefix to allow multi-tenancy.  

[Mark]

55 minutes ago, datakick said:

This was always the way to go. Ever since the first version of prestashop, this is how you move from one domain to another. There are thousands of tutorials on the interned describing the process.

In short:

1. backup database
2. copy all files from source to target server
3. extract db dump
4. adjust configuration (db connection, cache servers, server urls)

This will, of course, keep the original table prefix. But who cares if tables starts with ps_ or tb_ or ps_db_34fslj, it's just prefix to allow multi-tenancy.  

Thanks @datakick it doesnt matter if there are no table names in the code, but I dont know if that's the situation or not. But from what you are saying there isn't so thanks for that I shall try that

[datakick]

52 minutes ago, Mark said:

Thanks @datakick it doesnt matter if there are no table names in the code, but I dont know if that's the situation or not. But from what you are saying there isn't so thanks for that I shall try that

I'm sorry, but if you don't know such *basic* info, you shouldn't do this task at all.

[Mark]

20 minutes ago, datakick said:

I'm sorry, but if you don't know such *basic* info, you shouldn't do this task at all.

Actually no, Ive never read the codebase for whether it has table names nor should I ever ever have to. Are you a bit desperate for cash @datakick

Edited April 8, 2020 by Mark

[datakick]

25 minutes ago, Mark said:

Actually no, Ive never read the codebase for whether it has table names nor should I ever ever have to

I have a car. I know how to drive it. I know how to turn on the radio or how to use navigation. 

But I don't know how to change the break master cylinder, or what kind of oil filter it uses.

Nor should I ever ever have to. 

There are car mechanics that know this stuff, and can fix this for me much faster. The result will be better, and probably much cheaper, then if I did it myself.

With thirtybees (or any other ecommerce platform) its the same. It's designed to help you sell stuff online. And it's pretty good at it. But it will not magically migrate itself from one domain to another. You need more than a user level experience with the system to do this. It's not a shame if you can't do it yourself. Just hire somebody who can. Like I hire car mechanics to replace oil for me.

[Mark]

9 minutes ago, datakick said:

I have a car. I know how to drive it. I know how to turn on the radio or how to use navigation. 

But I don't know how to change the break master cylinder, or what kind of oil filter it uses.

Nor should I ever ever have to. 

There are car mechanics that know this stuff, and can fix this for me much faster. The result will be better, and probably much cheaper, then if I did it myself.

With thirtybees (or any other ecommerce platform) its the same. It's designed to help you sell stuff online. And it's pretty good at it. But it will not magically migrate itself from one domain to another. You need more than a user level experience with the system to do this. It's not a shame if you can't do it yourself. Just hire somebody who can. Like I hire car mechanics to replace oil for me.

I can and do happily pay coders to do things on my own systems or open source projects Im involved in. I dont even involve them if its core stuff that should be done as part of that core project.

I can certainly do this myself, I just had concerns around whether it would work for reasons Ive highlighted and they were just concerns.

You and others have sadly been trapsing around trying to get me to pay for things that should be core and thats unfortunate @datakick maybe try a gala or something to raise money if you cant do it with this company

Edited April 8, 2020 by Mark

[datakick]

3 minutes ago, Mark said:

I can certainly do this myself, I just had concerns around whether it would work for reasons Ive highlighted and they were just concerns.

Well, this whole thread is an evidence that you can't, actually 

3 minutes ago, Mark said:

You and others have sadly been trapsing around trying to get me to pay for things that should be core and thats unfortunate

Me and the others have tried to help you with this task. Well, not me personally, as I've come to the conversation quite late. But others spent a lot of time and effort to help you. You just don't want to listen.

Migration from one server to another *is not* a standard functionality. It's has nothing to do with the purpose of the software -- to sell the stuff online. Just like with the car simile. Its purpose is to drive you around, and it does this job just fine. But it will not replace oil filter itself. You wouldn't expect it to, would you? 

3 minutes ago, Mark said:

@datakick maybe try a gala or something to raise money if you cant do it with this company

Thirtybees company earns a lot of money. But it's kind of you to worry about that. 

[Mark]

3 minutes ago, datakick said:

Well, this whole thread is an evidence that you can't, actually 

Me and the others have tried to help you with this task. Well, not me personally, as I've come to the conversation quite late. But others spent a lot of time and effort to help you. You just don't want to listen.

Migration from one server to another *is not* a standard functionality. It's has nothing to do with the purpose of the software -- to sell the stuff online. Just like with the car simile. Its purpose is to drive you around, and it does this job just fine. But it will not replace oil filter itself. You wouldn't expect it to, would you? 

Thirtybees company earns a lot of money. But it's kind of you to worry about that. 

Cool although I havent even looked at this thread since I posted until now. And as youve said, there was only one correct answer. I also agreed but was not sure over table names. Your reply indicated there was no need to be concerned so my next step was to actually try it, which have not yet done. Its somewhat dangerous to presume the other guy is an idiot

Edited April 8, 2020 by Mark

[toplakd]

Start with this.

On 3/17/2020 at 11:59 AM, Traumflug said:

Chances are good one imports this trouble by importing the old database. Starting from scratch with an old database doesn't make much sense.

To clean an existing installation:

• Uninstall and delete all non-thirty-bees-modules,
• delete all overrides, which means, all files ending in .php in overrides/, except index.php,
• Use Core Updater to update the installation to have no obsolete and no modified files.

To move from one domain to another, move/copy all files and move/copy the database. This should give a working back office. To move front office as well, adjust the domain URL in Preferences -> SEO & URLs, third panel from the top.

 

And end it with installing consistency checks module to make some more checks.

And if that's too much, i suggest to hire someone to do it.

 

1 hour ago, Mark said:

Are you a bit desperate for cash @datakick

 

44 minutes ago, Mark said:

@datakick maybe try a gala or something to raise money if you cant do it with this company

Writing dumb questions and staements won't help you to upgrade / migrate your shop

Some users on forum are spending many of their time for free, to maintain the core and applying bugfixes.

Edited April 8, 2020 by toplakd

[Mark]

14 minutes ago, toplakd said:

Start with this.

And end it with installing consistency checks module to make some more checks.

And if that's too much, i suggest to hire someone to do it.

 

Writing dumb questions won't help you to upgrade / migrate your shop

Some users on forum are spending many of their time for free, to maintain the core and applying bugfixes.

Its great you guys do it free, I (and many others) do seriously appreciate that, I am not putting thirtybees/developers down, its some very good software youvve forked and worked hard at (for good reason), with much potential.

There really isnt that much need to attack me, Ive simply wanted to undertake a task and have waited for good advice before I did it, of which there has been a lot that I have not acted on yet because each of the solutions/answers needed fleshing out.

Edited April 8, 2020 by Mark

[oliver]

Soo, did you ever get this to work?

 

I'm needing to do the same thing right now, except that my old site is still running PS 1.6

I've succeeded up until the point that I can't log in with my existing customers, and - oddly - I can't even create new customers and log in with those O_o  

Super weird, and I'm seeing it might have to do with the _COOKIE_KEY_ 

Does anybody have any advice or experience with this? What difference is there in the way passwords are encrypted and stored in TB compared to PS?

And why would I no longer be able to log in with newly created customers after migrating my old DB over? O_o

[oliver]

1 hour ago, oliver said:

Soo, did you ever get this to work?

 

I'm needing to do the same thing right now, except that my old site is still running PS 1.6

I've succeeded up until the point that I can't log in with my existing customers, and - oddly - I can't even create new customers and log in with those O_o  

Super weird, and I'm seeing it might have to do with the _COOKIE_KEY_ 

Does anybody have any advice or experience with this? What difference is there in the way passwords are encrypted and stored in TB compared to PS?

And why would I no longer be able to log in with newly created customers after migrating my old DB over? O_o

Ooof, okay I fixed this...

The main problem boiled down to the old DB having the field for passwords limited to 32 characters, but the new db has it set to 60 characters.

 

Further, TB uses a better encryption method, compared to the old PS.

Any customers that are trying to log in, it will check if they still used to old encryption method. If yes, it will update their password with the new encryption method.

But, once again, the new encryption method requires 60 characters in the database, so the fields needs to be updated. ✌