We had developed an Umbraco based site for one of client way back using version 4.7.1.
Now when the client is demanding more additions to the existing project our development team has suggested the up gradation of Umbraco from 4.7.1 to 7.1.
Main challenges we face are
Have to completely redo the project.
Some of the packages used at that time are obsolete.
Convince the client for up gradation.
The team is not entirely sure of the benefits of up gradation, i mean client does not possess much technical knowledge .
Can anyone help on this.
Help will be much appreciated.
I have upgraded Umbraco installation from version 2 all the way up to version 6, and if you followed the upgrades, that would be fine.
Version 7 on the other hand is completely new and requires a different approach for datatypes, custom sections, etc..., and will require extensive rewrites.
The Umbraco upgrade (files and datbase) might not be such an issue, this is usually well tested by the umbraco team, but the extensions you wrote might pose some serious hurdles.
Upgrading to version 6 would be an option, though the benefits will not be that visible for the client. It is more stable, and has a lot of support from the community.
Upgrading to version 7 would also mean the editors need to get used to the new interface (which might be an issue, depends if you have 1 or 100 editors), lots of code rewrites (missing packages and datatypes), and a phase where the developers need to get used to a different coding style in the Umbraco 7 back-end (all done with angularjs).
Version 7 looks very nice though, and clients might be inclined to go for it and spend the money. If not, and you are on a budget and time limits, you should move as far as version 6.
It's always tempting to go for the latest & greatest version. Personally I'm waiting for v7 to get bedded in for a year to let other people work out what needs patching and I'll be developing new Umbraco projects in v6 certainly for 2014.
Given how bad the experience of v5 was I don't think the great reports of v7 are enough to tempt me this year.
On upgrading, the reality is, (http://umbraco.com/follow-us/blog-archive/2011/11/14/the-upgrade-myth.aspx) as Niels Hartvig put it - upgrading Umbraco is a myth. To go up from 4.7 to 4.11 is certainly do-able; I've done it following this guide (http://our.umbraco.org/forum/getting-started/installing-umbraco/36855-upgrading-from-472-to-4111).
But to try to upgrade from v4 to v6 or v7 is going to take longer & result in a worse site than building a new site from scratch. A lift-and-shift job that involves the switch to MVC from asp.net forms alone is going to take more time than a new site will take to build.
The real options you have are:
Justify a new build in v6 or v7
Build on what you have in v4
Depending on your budget, expertise & priorities either option could be a good one.
You should be able to upgrade from 4.7 up to the end of the 6 branch without any major issues, I performed a similar upgrade recently. If your site uses lots of packages or custom data types, I wouldn't bother jumping to 7, as most of them won't work with the new API.
The main issues that you are likely to run in are the change in version of ASP.Net, and you'll almost certainly have to update some of your 3rd party packages along the way. I documented my upgrade here.
If they desperately want 7, I'd consider a rebuild from scratch, as a LOT changed between 4.7 and 7. The main benefits of upgrading to the end of the 6 branch are that you get a big improvement in back office performance (especially when you have multiple editors working at once), an improved media library, and a number of nice bug fixes. Most of the changes are under the hood though, so your client might only notice the snappier response of the back office and the media library, so it could be quite hard to justify the cost to them.
Related
I have to upgrade website running very old version of Drupal (cannot even find out which version is that, but I guess it is even before 5) to the newest one? Is that possible? If yes, how to approach this?
The Drupal web site makes it clear that you cannot skip major versions when doing version upgrades.
See this page: http://drupal.org/upgrade/
(it talks about not being able to skip from v5 to v7; it doesn't even mention v4!)
So if you do manage to upgrade your site all the way from v4.x to v7, one thing is for certain - it's going to be a long-winded process.
The other thing that is going to be a major issue for you is that the Drupal module ecosystem has changed radically in the space of time between v4.x and v7. Many modules that you'll be using in v4 will be either unsupported in later versions, or not have an upgrade path, so you may have a lot of manual hacking to do.
On the flip side, there are likely to be newer modules that can do things in recent versions of Drupal which were not possible in older version or were done in a very different way, and you may find yourself wanting to use some of those modules instead of ones you've got in place. Again, lots of manual work I forsee for you.
In summary, I would suggest that upgrading from such a long way back to the current version is going to be extremely difficult. You may find it easier to start again from scratch and rebuild everything. I'm sure you could get some data imported from the old site to maintain continuity.
One further thing I would add is that this isn't a Drupal-specific problem, so please don't blame the Drupal developers if you struggle with this upgrade - you'll get this issue with virtually any software you run if you don't keep it up-to-date. Try upgrading a Windows95 machine to Windows Vista and you'll see what I mean.
It would be possible, but could be very hard.
You would need to go from 4 to 5, then 5 to 6, and finally 6 to 7. You will have to make sure that your data is still intact along each upgrade and back up your database. Update any contributed modules and check if any have been deprecated along the way and find suitable replacements if possible.
Depending on your site, if it is just the content and you are not concerned with losing url aliases, taxonomy terms, etc. then trying to export/import your raw data directly into a fresh drupal 7 install might be easier.
Edit: You would also need to upgrade any custom themes and modules drastically.
I do not envy your task, as you will need to learn the changes from D4 to D5 only to later discard this knowledge as you learn the changes to become D6 compatible and then discard that knowledge to become D7 compatible.
As you said you do not really care about losing taxonomy terms or extras, you might want to try http://drupal.org/project/import_html or a similar module to scrape your website (though it is not actually static) and convert it automagically into nodes. That module is not currently available in D7, but would get you from D4 to D6.
The key thing to remember is frequently backup your database in case anything goes wrong or you want to try different upgrade paths.
It is doubtful that many contributed modules you are using would survive the upgrade, unless there is a release for each of versions 4, 5, 6, and 7. I agree with #brian_d, the best course of action may be to export your content and import into a fresh Drupal 7 site.
The general procedure for updating:
Assuming you are on version 4.7.x of Drupal:
Update Drupal and any contributed modules you can to the latest release for 4.7.x, in case there were schema changes
Disable contributed modules
Update Drupal to the latest version of 5.x
Update and re-enable modules/themes to the latest release for 5.x
Repeat steps 2-4 for 5.x to 6.x and again for 6.x to 7.x
I've been using Drupal since 4.x. During that time I've had to upgrade numerous times. Mostly I've had good success using the standard upgrade process. However, I've had to do several upgrades manually because of one issue or another. This was basically a Copy and Paste upgrade.
To read more about the Copy and Paste Upgrade go here: Upgrading Drupal by Copy and Paste.
I am trying to work out what is the best way to upgrade www.edocr.com, which is built on Drupal 5 to Drupal 7. We are more than a mere website.
If the answer is, start new with Drupal 7 and then import content, this also opens up another question, i.e. should we ditch Drupal completely and use a php framework such as http://www.yiiframework.com/, which would of course be a costly exercise. Could we achieve the same level of performance that a framework such as yii could offer through Drupal 7?
Many thanks in advance.
I've had to do upgrades from 5 to 7 and this is my experience. Upgrade everything, piecemeal to 6, then to 7. The schema changes between 5 and 7 are huge and you don't want to miss anything. That is going to be a cost to you.
If you have a content specialist, create a separate Drupal 7 site and then have the specialist recreate the content in 7 from scratch. This has the added benefit of everything being clean in 7 and you don't have to worry about schema changes during upgrades...this is a cost to your client.
As far as frameworks versus Drupal, it is a wash either way. Drupal is free, but the time for supporting it is not. You spend more time figuring out how to do things in Drupal than developing. Whereas with custom frameworks, you get the benefit of doing it yourself the way you want, but at a longterm cost of having to support the code over the course of its lifetime.
I'd say, if your client is happy with the modules, they can accomplish what they want in Drupal, and there is nothing prohibiting you from getting your messsage across, stick with Drupal. But if the system is coming up short in lots of areas, definitely weigh the cost of developing and supporting custom code to time spent customizing Drupal....remember, free software is only free at the outset...not longterm.
The general way of updating a Drupal site for a major Drupal release is to:
Upgrade Drupal core
Upgrade contributed modules.
Upgrade theme / create new theme
In your case you need to do 1-2 twice and 3 once. It also becomes a bit tricky since, you might be missing modules from D5 -> D6 and D6 -> D7. You will need to do some investigating as some modules are merged in new Drupal releases, while others just disappear.
You can try out doing the 1-2, 1-2 a few times a see what happens. It might give you an indication of how much work is needed to actually get your site upgraded.
Okay today, as most of you noticed Framework 4.0 has been released. I've been working on a project which is being built on framework 3.5. Since I want to use dynamic keyword and most of the asp.net features like Tableless Menu Control, ClientIDMode and clean web.config etc. I am kinda urging to migrate the unfinished project to 4.0 but I am little hesitating about that.Some times I think it is way better to wait for SP1.
So what do you think about it? You guys will migrate to unfinished projects or will still hang out with 3.5 for a while.
Thanks.
The .Net 4.0 runtime environment has been out for a while (mind you not RTM, but RC1 and so forth). A lot of people have tested it and I would guess that almost all of the bugs have been shaken out. There should be no problem switching at this point. They have introduced a number of items that improve .Net. Are they necessary, no, but they can make programming in .Net easier.
You can always download 4.0 locally and test it out on your project. Worse comes to worse, the project blows up and you reload it from your source control system.
What you should be aware of is that there are breaking changes in both C# and VB.Net in 4.0 runtime environment. You'll need to watch out for those.
The following probably applies to most framework-base development.
Do the new features save more time than fixing the old things the upgrade breaks?
If you're going to waste lots of time making old things work, perhaps you're better off just to sit it out on 3.x and port to 4.x at a later phase.
If you really need features from 4.0 and would have to spend time implementing them yourself, perhaps it's a net time saving.
Can you support this version of the framework? (ie can your server people handle the upgrades and monitor things okay?)
If your server bods can't make this work in the field, give up now. I don't know your organisational structure or who runs your servers but I know some companies have a pretty thorough testing regime they'll put software through before allowing it. As a brand new version, they might be weary.
And let's be frank, just because something goes through several pre-release versions, they don't catch every bug because they're rarely used in production scenarios. You know the drill.
And if installing 4.0 on the server breaks old things, you might be waiting a long time.
Is your project's launch likely going to be after the first round of bug fixes?
If you're developing this for 3+ months away, you've probably got enough time to sort the platform issues, fix the code issues and get framework bugs reported with the (blind) hope that they fix them or you can work around them safely.
If you're launching tomorrow, it's not enough time to test it.
I will only upgrade when there is a need to do it. For example I have one application that must use features delivered in .Net Framework 4. So that application will get upgraded ASAP.
I have another application that is 3.5 with no driving need to upgrade at this time. That one will get upgraded when time and budget allows.
I am preparing to start on a new short-term contract (1-2 months) that involves replacing an Access application by moving it to ASP.NET and SQL Server.
I am only responsible for the ASP part and connecting it to the database.
The only requirement is that whatever technologies I use be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.
So, I could do this in Rails or ASP.NET, but, when should the development be aiming for .NET 4 Framework, as there are many changes coming out that may be advantageous to use.
Or, even though it may be useful, when is it better to just ignore new features and stay on an older version of .NET?
I am assuming that hardware isn't the limitation, as many computers won't be able to run .NET 4 Framework, but that would be an issue for a hosting company, as they can find a hosting company to support whichever framework the application is designed for. If Rails makes the most sense, as their hope is to have the application written quickly, but have it reliable, then again, the hosting company would need to support it, or they use a different one.
This company hasn't used a hosting company, they need to find one, so there isn't a relationship that could be an issue.
UPDATE: Part of my concern is that initially the application will not require javascript, but phase 2 will be to make it more interactive, as some clients won't be allowed to have javascript on their computers. In order to limit how much javascript must be known by a developer there are frameworks that will adapt to browsers and situations fairly well, which is why I am also thinking about RoR and the fact that there appears to be changes coming out in .NET 4 that may help with this.
As a general rule of thumb, I wait one year before building sites in a new framework unless the client specifically asks for the newest technology. This has worked out very well for me. The advantages are:
The technology is much more stable (hotfixes, service packs, etc.)
Common complaints about missing functionality are usually resolved
Hosting companies, support communities and corporate IT departments have had time to get used to the technology, find out more about it, play around with it and have it mature within their organization
Unless there is specific need for new functionality introduced by .Net 4, there is no point in subjecting your clients to the immediate problems with an initial release, or making it more difficult for them to find hosting. You should either investigate all of this up-front, or use .Net 3.5 in the meantime.
The only requirement is that whatever
technologies I use that it be
relatively well-known in the area, so
that if they need to have someone else
work on it, it isn't specialized
knowledge.
I would have thought that requirement was enough not to develop this project on .NET 4.0 - it takes time for a new framework version to filter down into the market, and it will be a while yet before there are a lot of developers around with .NET 4.0 experience.
Also, you would be essentially developing on top of a BETA product - while I'm sure most of the features will remain unbroken from BETA -> RTM, there is always a risk that something will break or not work like it did in BETA, so why risk this on a commercial project?
I wouldn't target .NET 4.0 yet on a commercial project unless there was a specific reason for doing so, and even then you would have to have buy-in from the client, ie "I can do this much more quickly and with less effort if we use the current beta version X rather than established, stable version Y" - good luck with that.
I worked on a commercial project that used the CTP version of LINQ to SQL - then when we went to VS2008 / 3.5, suddenly everything changed and we had to make a lot of changes just to get LINQ to SQL working again.
Stick with 3.5 - it's easier for hosting and getting developers.
Just a couple of thoughts, I wouldn't even think about creating an application for production use in .NET 4/ASP.NET 4 until:
There is a release candidate. It's
not the first time I've seen
features in beta's not make it to
RC/RTM.
Microsoft have permitted development and deployment
of production applications by way of a 'Go
Live' license.
There are some hosters out in the market such as OrcsWeb who are participating in public beta testing, but they aren't intended for production use.
I'd run with the .NET 3.5/ASP.NET 2.0 or MVC bits for now. Better safe than sorry.
Generally speaking it's going to be easier finding hosting for a Rails app. If you want to run .net 4.0 you're probably going to have to run a VPS or dedicated machine. However if you're bailing after the application is finished and assuming your client is in Knoxville, they're going to have a tougher time finding a Rails developer to maintain the application.
I think the bigger question is your role. They're looking to you to solve this problem for them. Are you productive in both technologies? How about getting a Windows server up and running? A Linux server? How's your SQL Server vs MySql? I'd guess that you're probably stronger on one stack vs the other - for a contract that short I wouldn't want to be doing a lot of experimental development.
i wait until the OS that everyone will be using has it.
Just last month i took a dependancy on GDI+, which first shipped with Windows XP.
I'm planning to install Drupal. Is there any reason not to install the latest 6.x version as opposed to the 5.x branch? Are there any really good modules that are 5.x only?
Unless you have a 5.x module that you can't do without, and that you know is being worked on to upgrade to 6.x, just use 6.x. i.e. Only start with 5.x now if you know you have a upgrade path with your site to 6.x (and then 7.x). If the module isn't being actively worked on, it mean you'll be unsupported when 7.x rolls around, so you might as well solve the problem of doing without that module with 6.x now rather than wait till your site is developed and up and running.
I've found enough modules to happily run my site on Drupal 6.x I think the only 5.x module I miss is one that did very easy Google ad integration, and that may have been updated I just haven't checked recently. I don't get enough traffic to make the ads worth the time in setting them up, so I just use the search part of the ad campaign.
Drupal 7.x is under development now, so I would expect that anything that hasn't been moved from 5.x to 6.x is just not being developed anymore, and is probably not really that needed.
Ultimately, take a look at what modules you may need. With an account on Drupal's site, you can filter by install type. I found that 6.x is much easier to work with in some regards (managing and upgrading modules) and overall I've had a much easier time maintaining my site under Drupal 6.x than I did under 4.x or 5.x.
I also think that 6.x runs much faster.
My bosses were insistent on making Drupal 6 sites for clients as soon as it was released. This was a headache, because views and CCK were not done, as well as many other modules. Their rational was that we'd have to eventually upgrade to 6, and we wouldn't want to go back and redo these sites. It ended up that we had so many workarounds while using the development versions of modules that it was a pain every time we upgraded modules or core itself.
Thankfully, this is no longer the case. Views, CCK, and most other modules are now ready and stable for 6. The only module we use that hasn't been upgraded is eCommerce, and it doesn't look like it will be, since ubercart is pretty much the Drupal standard for commerce functionality.
We asked ourselves the same question several months ago (just before Drupal 6 was finalized & released)
Our office has limited development resources, and we had released a couple of D5 sites, and a D5 sales app.
We went with Drupal 6.
The decision came after considering the core of what we were interacting with. CCK & Views are the only die-hard critical components for anything besides a default Drupal install, and the level of participation and vitality of the projects was very encouraging.
The stuff that really, really matters, has been/is being ported over to D6, and the wow, this would be nice, p2 stuff is hit & miss.
If you're doing any module development, D6 is a winner.
If you're already very comfortable with D5, then stick with it.
I hope this helps.
The one significant CCK-related module that's not D6 production ready is filefield. This may not be an issue if you're not doing anything substantial with images and media, but might be worth considering if you're going to do any serious DAM. Otherwise, I think we're (finally!) to the point where it's making more sense to go with D6 than D5. Either way, it's definitely worth the time to architect the site according to your specific needs, figure out what modules you'll need and find out if any of them have yet to be updated.
The asset module is not available for D6 yet, not even in a development branch. I've heard a lot about its benefits as a single way to manage all kinds of media files, but most sites can probably happily do without it.
If you haven't been running Drupal before you could find that version 6 has the modules you need. Besides, modules gets ported and created every day so your missing modules could very well be on the way.
For me, the lack of a protx payment module was a deal breaker when choosing which version to use.
The best thing to do is get a full list of requirements before you start, and make sure it's all available in 6.
As a module developer, I feel that Drupal 6's API is more mature then version 5.
So even if you decide to choose 6, and then finds a module is missing, it will be easy to develop it to 6.
Now that I've used Views 2, I ain't ever going back (unless it's to revisit old projects).
I think now, all modules and themes that are of any worth have been migrated and now I'm seeing a trend of new (actually good themes) are drupal 6 only as are quite a few of the must have modules.