what is the best way to Import content from Tridion 5.2 to Tridion 2011 SP1, content porter? or Kapow
To upgrade the DB you would have to follow this path: 5.2 => 5.2 SP1 => 5.3 SP1 => 2011 SP1. This information can be found in the documentation available on www.sdltridionworld.com
Additionally you would need to:
1.- Rebuild store procedures.
2.- Rebuild search index.
3.- Optimize stats.
In case you want to migrate only bits and pieces you are looking into extract content from 5.2 using business connector and then importing this into 2011 using CoreService.
What about upgrading the database? Or are you going to sanitize content?
I would probably try Content Porter (due to cost) but take into attention all dependencies that might come with it.
Do you have two different Tridion environments set-up already? Is the content in your 5.2 environment old? Has it seen a lot of updates already? Does the code remain exactly the same (vbscript?) Does your client really want all the content, or just parts of it?
If it really is just a case of an upgrade without anything changes in code, design or implementation you should use Asier Fernandez's solution with the database upgrade.
Anything else that is going to be an upgrade of Tridion systems, but with many other site changes you should considers a more manual approach (cheaper in the end) Bart Koopman once wrote a ncie blog about it: http://www.tridiondeveloper.com/how-to-say-goodbye-to-your-migration-tool
I would like to ask why you think the sdl tridion advised way (database upgrade) is not in your options, as that is really the most safe way (if upgrade is what your goal is)
If you are also planning on cleaning up your database then i suggest to first clean up unnesesary items (components, pages, keywords, templates, schemas etcetc). When you are not able to remove items, use WhereUsed as you need to cleanup or disconnect dependancies. Don't think that a CP export->import will clean up the items that you could not delete during your cleanup, if you were not able to do it manually, cp will also not be able to, it will simply add the items to the package.
In my eyes, the only reason for a CP migration for upgrade is to cleanup legacy issues from older versions (db upgrade will keep them) but keep in mind, broken relations/items will fail in CP and you will need to manually create them in the target system, but this way you can get rid of legacy issues that will not go away
In my eyes, for upgrade only, use db upgrade, less effort, fully supported by sdlt support.
And my advice is to seperate an upgrade from ANY other requests, like new layouts, new functionality or cleanup, that way testing and bugtracking will be lot easier
Related
What are the kind of challenges faced when we migrate/move from versions of ATG commerce (<10) that were not using EndecaExp Manager to versions that use it. For ex, would all the JSPs undergo a change in the way they are rendered, given that the pages will now have to be template driven ?
What would be some best practices here to have a minimum impact of the move on the UI & maximize the reuse of the JSPs ?
I have read the migration docs but they do not seem to cover this aspect.
As you know ATG and Endeca only really started integrating in ATG 10.2.x. So in older versions of ATG the integration requires a lot more work from the developer. I've worked on an ATG 9.2 and Endeca 3.1.2 implementation that does exactly that. Your question should really be how far off are you from migrating to a later version of ATG that does integrate nicely with Endeca and how much of your current system would you want to retain after such a migration? This is important as it will mean you either need to build a solution that mimics the ATG Assembler Pipeline functionality (giving you the most control over your templates and cartridges when integrating with Experience Manager) or a less intrusive approach, based on the InvokeAssembler droplet.
The other thing to consider is how much do you want to render through Experience Manager. Typically you would do the homepage and category pages. The product detail page would call some components from Experience Manager (for example breadcrumbs) but the data in the index isn't usually as accurate as the data in the database (for example inventory levels) so for the PDP you go directly to the repository. You are also unlikely to build your checkout flow in Experience Manager. This should give you an indication that you are likely to retain a large number of your existing pages.
Your quickest approach would be to build a droplet that will retrieve your contentItems from Experience Manager and then start to render them. Keep in mind that the content items are just glorified JSON responses so you can easily parse them when you get hold of them.
i am using fly way to migrate the core product from older version to newer version. This work wonderful.
But I have a case, where we want to migrate customization specific script on top of Core product version. As you know, each client may have different customization.
For example.
Say core version is 2.2.1.
Customization 1 version is 1.0
Customization 2 version is 1.0
Now i would like to apply flyway similar to this
V__description.sql
For the above example, it would be like
V2.2.1_1_1.0__ThisIsCusotmization1.sql
V2.2.1_2_1.0__ThisIsCusotmization2.sql
This is little cumbersome for us.
Is this possible to use alphabets/alpha-numeric in version names like below?
V2.2.1_CUST1_1.0__ThisIsCusotmization1.sql
V2.2.1_CUST2_1.0__ThisIsCusotmization2.sql
V2.2.1_RC1_1.0__ThisIsCusotmization1.sql
Note: Moreover, I could nt see any significance of using prefix (V) here. Please let me know its purpose. Also please let me know whehter we can use more than one prefix like one for core product and other for customization.
From the sound of your question, you probably should go for two Flyway instances. One for core, managing only these changes and another one for the customization.
Each could then be configured with a different location to resolve the migrations from.
Are there any known issues/complications for migrating code that is using the Tridion Business Connector during a Tridion 2009 to 2011 SP1 upgrade?
I know that the migration from R5.3 may cause problems because of the fact that Categoies & Keywords are now hierarchical. Are there any likely to be any simillar issues with an upgrade from 2009 to 2011 SP1?
**I understand that the Business Connector is deprecated, and likely to be removed in the next version and that Tridion recommend that the code is rewritten to use the core Service. However, the client is likely to rewrite this code in about six months anyway (with the introduction of some new business rules) and just wants to migrate it 'as is' during the upgrade.
Thanks,
Jonathan
There's only one known issue for it: If you are sending requests using UTF-16 you will need a hotfix, otherwise everything remains the same
Aside from the Business Connector being deprecated (it still works fine btw) the only other thing to be aware of is the addition of some new (optional) elements in the various XML formats. If your XML handling is written well, no changes should be needed. If you depend on the exact XML structure, you might have to add the new elements into your XML templates.
The new element that I'm most aware of is called ExtensionXml and appears on Schemas and Fields. The documentation has an example of how ExtensionXml is used (with the Core Service, but it might be a good example for when you want to set them using the Business Connector too).
We are a software development company and are using Wordpress for static portion of the web site. Naturally, all our workflow is built around version control: multiple developers -> continious integration -> staging -> deployment.
Our challenge with integrating Wordpress into our workflow is that its database is stuck like a bone in the throat: you cannot put it into the version control, easily roll back, promote from staging to production etc.
I am wondering what people do in similar situations? I would like to find a way to integrate WP into the development workflow and not the other way around :-)
Clarification we want to "develop" and test pages on the staging system and when ready then move them over to the production as part of the version upgrade process. We don't want to do full replication of the staging database to production.
That's a common question and one that I've worked on tackling. I've written some code to address these issues albeit the code's not ready for distribution. Basically the idea is to create scripts to import the content and then version control the scripts. (Actually my approach uses a custom import/export format designed to be easy to hand-modify, but the idea is similar.)
Anyway, there are some related questions over on StackOverflow's sister site WordPress Answers:
Questions tagged with the term [staging]
Questions tagged with the term [deploy]
UPDATE
Per the clarification, this would probably be helpful too:
Is there any way to draft a revision of a published page or post? What workarounds have you used?
Hope this helps.
-Mike
I've just hit the same problem. For now we are using MySQL dump files to export/import database content, but it gets ugly with several people working on the database changes.
Since the team that works on the project is all internal and consists of just a few people, I'm thinking into the direction of locking the database dump file in VCS. Subversion had this functionality built-in, but we are using git, which, I think, is conceptually opposite of any kind of locking.
Probably we'll have a workaround script with pre-commit hook to check for the existence of a lock file next to the dump. The person who committed the lock file will be the only one allowed to commit the dump. Once he finishes the work, he will need to commit the removal of the lock file.
It sounds ugly, I know. But I've thought about it for a while and don't see an elegant solution yet.
If you're only using WordPress for static content, then any tool/methodology for version controlling databases should work - for example, work the mysql command line tools into your CI and deployment routines.
I was wondering how teams that develop sites using Drupal (or any other CMS) integrate version control, subversion, git or similar, into their workflow. You'd obviously want your custom code and theme files under version control but when you use a CMS such as Drupal a lot of the work consists of configuring modules and settings all of which is stored in the database.
So when you are a team of developers, how do you collaborate on a project like this? Dumping the database into a file and putting that file under version control might work I guess, but when the site is live the client is constantly adding content which makes syncing a bit problematic.
I'd love to know how others are doing this.
You are correct that this is an issue for Drupal--version control works fine until you turn the site over to your client or open it up to users.
Your question seems like a more specific version of this one, which touched on version control in the Drupal workflow. You may find some answers there that help.
For some projects, I have exported all of the views to code, using that feature of the Views module, and I have one project where all of the blocks have been exported, as well. (Although that was a development exercise and not a customary thing to do with blocks.)
Take a look at the work that Development Seed is doing to work around this problem. They are leading the development of the Context, Features, and Spaces modules that work together to store configuration data in modules (outside of the DB) so that it can be versioned with the code.
There is a Drupal group called Packaging & Deployment for discussing the various solutions that are being developed for this issue.
Right now there are a lot of efforts towards creating something that will handle the dev -> production difficulties with drupal in relation to the database. Features, that flaminglogos mentioned is one, but I feel that is more focused on creating stand alone projects, ie ones that would be installed on many sites.
For simple maintaining you dev and prod databases I'd take a look at http://drupal.org/project/deploy and http://drupal.org/project/dbscripts. They support syncing and merging db side drupal config data.
I can't guarantee they are ready for prime time though...
There is a lot of effort of shipping the next drupal version with configuration in code. That's is the key to have it in a version system.
For now you can use the features module, with that you can export things like content types, views, etc. to code, and then compare, version and revert it as you need.