Metastorm 9.0 - Benefits for the end user (compared to 7.6)
Hi,
Can someone list the benefits to the End User of converting an existing 7.6 system to 9.0?
I know 9.0 supports multi langugage, but apart from that what are some of the other benefits to the end user?
It will take us 5+ months to convert existing 7.6 maps / admin forms to 9.0 and its difficult to justify the cost if there are not many benefits to the end user.
Regards,
Hemant
Comments
-
So far, most of the enhancements are on the development side. For the Client User Interface so far we have Reports added, Custom lists (of limited value, however), and latest of all, status fields in grids.
What will be coming in the next release may be of more interest, however, as I understand we will have Rich Text Memo fields, the ability to add custom controls, and Business Objects that are managed by code rather than being linked to the database.
More here:
0 -
As always, there is no easy answer to this. It very much depends on what you are doing with v7, what you may be planning to do, issues you may have etc. Metastorm do have documents that go through the benefits but you will have to weigh up the business benefits for you. Have a look at the Metastorm site or customer zone.
Your question was about end-user benefits but bear in mind other factors as well such as development environment, support and maintenance, stability, performance, integration etc. etc.
0 -
According to Metastorm End Of Life Dates general support for v7.6 will end on 31st May 2012, so it will have to be done at some point. However being 18 months out, v9.1 will be well established so users should see more tangible benefits.
I know a huge minus for our uses with v9.0 is that word wrapping is no longer available in read-only grids which is automatic in v7. I hope that is one of the issues they address with the next release.
0 -
For us its a decision between converting to 9.0 vs replacing Metastorm with .NET. If its too much effort converting to 9.0 without much benefits for the end user, then the client may re-write the application in .NET. I will be doing a POC for 9.0 soon which will help the client decide. I recently took 9.0 delta training. I do see lots of benefit for the developer, but wasn't sure what 9.0 has to offer to the end user.
Thanks Jerome/Paul/BMellert for the response. We use msrs reports, so the 9.0 reports wont be of much use to us. I shall read about custom lists and status fields in grid to get more understanding of it.
Jerome, I read your other article. It was very useful.
Paul/BMellert, have you guys converted existing production applications to 9.0? I was more curious to find what approach you guys took for migrating existing 7.6 data to 9.0.
Thanks,
Hemant
0 -
Paul/BMellert, have you guys converted existing production applications to 9.0? I was more curious to find what approach you guys took for migrating existing 7.6 data to 9.0.
I have done some preliminary conversions of an smaller (simpler) maps. I haven't tried the data migratior yet.
We would have been in full blown migration this past year, but other project took priority so we have not started proper migration yet. We will be doing so early next year. (I do know the non-word-wrapped read only grids is going to be an issue with my user community, and hope they provide that capability again in the next release.)
I'm of mixed feelings about what I have converted thus far and have not decided if we'll do a file convert then spend a lot of time editing the BOs and v7 left-over code into v9 visual scripts and C#, or if we will just develop from scratch referring to the v7 code. It may be a mix. I'm not sure if a file migration is needed to do the data migration, so that may be a factor as well. Either way we will be doing a fair amount of redevelopment.
0 -
We've converted some and rebuilt some. Both take time. Our findings so far:
For both approaches, you need to rename everything that would get automatically renamed (do the conversion and find out what gets changed, then rename manually) to get best results. Also, name your grids, every one of them, or you will find it very hard to match up with the created BO. We recommend our naming convention as there are so many different types of BO for different uses. You do need to do the file conversion for the data migration, even if you do not use the migrated file.
As for rewriting, all code have to be rewritten eventually. The easiest way is to write C# code, but we find Visual Scripts to be much better for documentation where possible.
As for rewrite vs migrate, if the process has become overly complex, a rewrite form the ground up can be very beneficial. The time taken may be less than testing all migrated functionality, to be honest. The advantages in leaner processes can be great, and the ability to take advantage of new and improved functionality such as looping and 'proper' code instead of script, can also be great for performance and maintainability.
Whatever you do, it will not be quick, and will probably not be easy, so make allowances now.
0 -
hmmm.... reading your feedbacks, it does seem there will be a lot of effort converting existing maps to 9.0.
Jerome, for data migration (existing 7.6 folders in the data base) did you guys use to data migration utility provided by metastorm or some custom approach?
0 -
Yes, we used the data migration utility for Folder data. A custom approach would be amazingly difficult.
We then had to migrate our own related data manually, which is a lot easier.
0
Categories
- All Categories
- 123 Developer Announcements
- 54 Articles
- 156 General Questions
- 149 Thrust Services
- 57 Developer Hackathon
- 37 Thrust Studio
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 918 Core Messaging
- 84 Digital Asset Management
- 9.4K Documentum
- 33 eDOCS
- 190 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 10 XM Fax
- Follow Categories
