views:

119

answers:

5

I'm currently trying to convince management of the need to port one of our applications to .NET. The application has grown to be a bit of a monster in Access (backend in SQL), with 700 linked tables, 650 forms/subforms, 130 modules and 850 queries.

I pretty much know all the major benefits of doing this, but now need to look at how this can be achieved technically, so I can put a project plan together.

So, my plan was to convert the queries into stored procedures and/or views on the backend and re-write the forms in WPF or WinForms.

Now, the code is where I come unstuck. Is it possible to packaged up the code behind and modules into dlls and consume them whilst it is slowly ported to VB/C#?

What we can't be left with is half an application in VB/C# and half in Access, it must 'appear' to all be one application, even half way through the migration.

Thanks in advance.

EDIT: Just some more info about what we do and why we're looking at moving away from Access.

We are essentially an ISV and the Access application is our main product. This application has been developed over a period of 15 years, by many, many developers on an ad hoc basis. There is no documentation for this application.

We also have problems with getting branching in SCC to work properly, so we've currently got 4 or 5 code bases for the half a dozen clients we have. On top of that, all the testing we do is completely manual, which you can imagine is very labour intensive, and only scratches the surface of what really needs to be tested.

We're currently looking to expand, and have a number of sales leads that are in the final stages. I'm worried that with these new sales, we're going to be swamped with support and testing, and that this application is going to become even more entangled an buggy.

I'll also add to this the fact that we're just about to enter the spec phase of a brand new product, which is almost certainly going to be built in .NET. If we were to rewrite the Access application in .NET, then the people we use for that can go straight on to this new development. If we were to stay in Access, then we'd have to get some new Access people in, whom would have to be retrained once we start the new development.

So essentially it has come down to two choices, major refactoring work in Access to try and 'organise' the code a bit better, and those of you who have suggested culling parts are most probably right; I'm sure there are parts that are no longer used. However, I fear that if we stay in Access we still won't be able to build in effective testing and we still won't have proper SCC branching, which will lead to support continuing to be a nightmare, and any future developments on this product makings things worse. Either way there is a lot of work that we're about to embark on, which is either going to be done in Acces, or .NET.

+2  A: 

650 forms/subforms is large by any standards. That represents a major conversion project, and a 'slow' port will be a nightmare.

I would suggest developing a new .NET application 'spike' that contains the basic functionality that is absolutely required and then build upon it. At the same time, freeze the Access application from all but essential fixes.

There are a few tools that will convert MS Access forms to .NET, but they will likely fail on complex forms with sub-forms.

'Effortlessly' Convert Access Forms to VB Objects

Mitch Wheat
I'm with you on the idea of not trying to port the whole thing, but wouldn't it be better to leave the old functionality in place while doing new work in a new platform?
Steven Sudit
@Steven Sudit: That's what I was suggesting (obviously not well enough! Updated...)
Mitch Wheat
Mitch, if I understand correctly, where our advice differs is that you recommend porting the basic functionality first, then building on it. In contrast, I'm saying it might be best to build only new functionality with new tools, forcing the users to keep use MS Access for existing tasks.
Steven Sudit
Mitch, in commenting on Ladislav's answer, I think I figured out what the big difference is. You're talking about replacing an MS Access app with one that initially does less. This is a hard sell. I'm suggesting a new app that does new things, albeit touching on some of the old data. This is an easy sell, and also sells the centralization of data onto SQL Server.
Steven Sudit
I agree that 650 forms sounds like a lot. It suggests to me a great deal of duplication, like I often encounter when I take over user-created Access apps. Very common is the same report layout saved multiple times with a different Recordsource, as opposed to using one report layout and assigning the Recordsource at runtime after collecting user input. This can also apply to forms, but in my experience, it's more common with reports and queries than with forms.
David-W-Fenton
+5  A: 

Instead of telling you how hard it is -- which I'm sure you already realize -- I'll try to toss out some hints:

1) Start by moving everything you can out of MS Access and into MS SQL. This means tables, stored procedures, views, etc. If you get this step right, your MS Access app will be a front-end for a real database, which is already a win.

2) Consider giving up before you start. Instead of porting everything, it might make more sense to recognize which features can just be left alone, while new ones get WCF or MVC front-ends.

3) It's tempting to port from VBA to VB.NET, on the theory that it's more similar, but I don't recommend this.

Steven Sudit
+1. Even though I didn't mention in my answer, I have gone the route of (1) before, but then the application was left that way; i.e. an Access frontend and SQL Server backend, because it worked well, and so no further upgrade was pursued.
Mitch Wheat
@Mitch: Once the data has been liberated, you have many more options, including mixing and matching UI's. The problem is that you often have to move business logic from VBA to T-SQL, first.
Steven Sudit
Courageous answer. Beware the Darth Vaders of the ms-access tag. http://meta.stackoverflow.com/questions/51441/most-and-least-dangerous-tags-to-answer-among-the-tags-with-1000-questions
Hans Passant
@Hans: I've been bitten by two of the Darths already, so I know what you speak of. Fortunately, I am protected by a strong apathy regarding my SO number. :-)
Steven Sudit
I don't quite understand the idea that the data in an app that is already linked to a SQL Server needs to be "liberated." If one defines "liberated" as "not being in Jet/ACE" then it already has been.
David-W-Fenton
Your step 1 can't actually be done in a traditional Access app with ODBC linked tables. You can't just move all the stored QueryDefs to the SQL Server, as views can only be used in Access through code, or as linked tables (which adds to the number of linked tables) or with passthroughs (which are saved QueryDefs, so you're just going in circles), and SPROCs have their own set of issues. It seems to me that you really mean port the MDB front end to an ADP front end.
David-W-Fenton
@David: Fully liberated would mean that the front end is not MS Access.
Steven Sudit
@David: No, I mean moving the data all the way into SQL Server, natively. If we need to set up MS Access QueryDefs as a way to connect to SQL Server's sprocs, that's fine. The key is that MS Access becomes expendable, so that we can throw it out. Remember: we don't want to develop in MS Access.
Steven Sudit
I still don't understand your point. The back end is already SQL Server, and you said "once the data is liberated", which indicates to me that you are talking about, well, THE DATA, and not the application. I don't think you have an actual justification for your assertion about "liberation" and you're just trying to make up an after-the-fact justification for saying something silly.
David-W-Fenton
Your answer is fine as it stands (nothing wrong with it), but your comments are worthy of multiple downvotes. I'm not going to downvote your answer because of your ridicilous comments, but I'm sorely tempted to do so.
David-W-Fenton
David: I don't really care if you downvote me. It won't make MS Access any better.
Steven Sudit
+4  A: 

I'm working in department which is mainly responsible for replacing old Access applications with .NET solutions. In my company Access applications are used for simple scenarios to fulfill business needs of single employee or small group of employees.

Sometimes Access application grows, group of users grows or too many changes are needed. In that case department using that Access application can start a project to recreate application. When this begins we can be sure that new application will be far away from current Access application.

First the business analyst is assigned to the project. His responsibility is to map current solution and to discuss problems of the current solution and expectations for the new solution. I haven't seen a project where "customer" wanted only replacing of the current solution. Everytime the customer also wants some new features and extensions which were not possible in Access.

Business analyst creates some initial description of expected solution which is passed to architects. Architects decide which type of application will be build, what type of HW infrastructure will be needed and how the application will be connected to other systems (if needed). After this initial phase IT have big picture about application and about needed changes. Here some initial estimate is done so project can be planned and resources can be allocated. This estimate is boundary for the project. Than my team starts to do the job.

We are using agile approach so our customer (internal team) incrementally sees new features in the application. First we gather some initial set (backlog) of user stories (special form of requirements) and we estimate these user stories and we let the customer to prioritize them. We choose subset of user stories for iteration (usually 2-4 weeks). New user stories can be added to backlog any time but our selected user stories can't change during iteration. After the iteration we present customer working part of the software. Based on the working part customer can decide to change priorities in backlog or create new user stories. We repeat this approach until customer says stop or unit budget is consumed. The important point is that not all user stories have to be done. Project has been planned with some budget and some low priority user stories don't have to be overtake.

From the technical point of view it is project as any other except few differencies:

  • You have initial database and you always have to be sure that already implemented part in your new solution also have working migration of exisiting data.
  • You have existing UI. Users can like or can hate the UI. Make sure that you understand it so that you create UI which is not worse than existing one. I created applications where UI had to be completely different and I created applications where UI had to be exactly the same so that users didn't need additional training.
  • Try to add some new features so that new application is reasonable. It is always easier to explain needs for the new application if you can describe new needed features.
Ladislav Mrnka
Good points: 1) Don't sell it as a lateral move; always offer new functionality. 2) Expect Access apps to need replacing if they get big enough, and plan for this. 3) What you're replacing may well be broken in terms of the UI or DB, but you need to understand it well enough to continue to fulfill business needs.
Steven Sudit
By "wants some new features and extensions which were not possible in Access" you probably mean "wants some new features and extensions which COULD NOT BE IMPLEMENTED in Access BY USERS WITH NOVICE-LEVEL ACCESS PROGRAMMING SKILLS." There are really very few things that are actually impossible in Access.
David-W-Fenton
I think it would be ridiculous to even think of proposing a lateral move -- where's the value in spending all the money and then getting no improvement? I can't imagine why any department would agree to spend money for any project that did not offer substantially more than what their existing Access app already provided, so the idea that there's something imaginative or innovative about the bright idea of including new features in the port seems ludicrous to me.
David-W-Fenton
What we're looking for though is a massive improvement in being able to effectively support and maintain the application.
James Ludlow
Have you ever tried to sell a completely lateral move on the base of enhanced ease of support and maintenance? You will get no buyers.
David-W-Fenton
@David: Lots of people, unlike you, would prefer not to develop in MS Access when there are alternatives. That's just the way it is.
Steven Sudit
@Steven Sudit: you seem to be adding a comment here on this answer that doesn't have anything at all do with this particular answer. Obsess much?
David-W-Fenton
@David: I commented here, in agreement, right after Ladislav posted his answer. Consider that his job is to port existing apps away from Access. Think about that a bit.
Steven Sudit
+1  A: 

So if a user is in Access and they take an action to open a form that happens to be a different executable written in C#, won't it 'appear' to be the same application?

There has to be a user group that would love a separate application that only has the 5-10 forms they use.

Getting rid of tables/forms/features that are not used is an increase in functionality. I don't know the level of documentation for this app, but start there. When users find out they have to document areas of an application and justify the need for parts they don't use, they'll volunteer to have it removed.

Jeff O
This is a very good point. I would not be at all suprised that with a user-created app of the size of this one if more than half the objects are legacy objects that no longer serve any purpose. Before doing any porting the first step would be culling the app to get rid of stuff that is redundant and no longer used, then looking at what's left and seeing how much of it can be reduced again (such as duplicate report layouts with small differences). I wouldn't be surprised if 3/4s of the objects in an app this size were not elimated entirely by a review of this kind.
David-W-Fenton
I very much agree, a cull before starting documentation I think will now be on the cards no matter which road we end up taking.
James Ludlow
+3  A: 

I been involved in a lot of migration projects where one is converting from one platform to another. I've also seen spectacular cost overruns, and spectacular under estimations of how difficult these types of projects can be.

In some of the projects and platforms I've created and that I had built for about $25,000, the cost of replacing this application and rewriting it resulted in the other team of people taking over this project and the resulting cost was in excess of $750,000.

You're also making an assumption that the current system needs to be replaced. You MUST have clear in your mind what the actual goals of moving and replacing the current platform and software are. Simply rewriting something and moving the functionality over to another platform yields you very little, except spending a lot of money that really doesn't benefit your business of all (but hey those developers will take the money, if they convince you of the need of doing this)

You might want to take a read of this wonderful article by Joel on software (Joel by the way developed and created this forum stack overflow – and I was a moderator of some of his discussion forums for almost 10 years),. In this article, Joel warns and gives caution against out of the blue simply rewriting perfectly good software that does not rust or wear out.

**Things You Should Never Do, Part I by Joel Spolsky

They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch. Article here: ** http://www.joelonsoftware.com/articles/fog0000000069.html

Joel continues to note that in the past 10 years, that article still remains one of his more popular ones (and somewhat controversial)

It makes no sense to take a perfectly good running application that's been running great for 10 years and doing its job, and then simply rewrite it in another platform, especially if you don't have the Manpower and expertise and personnel available to maintain this new system. And this is especially more so, if the new systems not going to accomplish anything more than what the previous system was doing. In fact if you did have that Manpower, they'd likely already have STARTED converting this system already over time. I mean why all of sudden out of the blue did someone throw a light switch and all of a sudden realize that new developers need to be brought in to rewrite a system that's already been running fine?

I'll also point out having been in this business for a long time (both published and technical editor of access books) I also done migration projects from mainframe systems to desktops . And, I also done migration of desktop database systems to large mainframe systems .

I can only say that it is rare to see an application with that many tables. In fact this issue raises alarm bells right off the bat.

Because of such a large number of tables here, I have to think that there's likely either very many processes, and multiple applications cobble together here that represents this whole system . If this is not the case, then of course rewriting in .net does not make sense unless you address the un normalized nature of the system. The fact that the data is already in SQL server helps, but that just might mean that you had the horsepower and capacity and infrastructure to scale something that was poorly designed and the first place

A very big major portion of software flexibility comes from having properly normalized data models. The problem you have is that you have the data in SQL server, and it's very tempting to rewrite parts of the forms and functionality as .net forms, and continue to use the current existing data models. Unfortunately this put you in a bit of a rock and hard place, because you want to continue to use existing data, and start rewriting functionality in .net. However rewriting of functionality in .net without addressing the data models is a very bad idea.

In an ironic twist of fate, this is a catch 22, because likely if that system had really fantastic great designed data models, you might not even have the need to redesign and move this into .net. Access and SQL server can scale out to 100's of users with ease anway. And, access supports the use of class objects, and even source code control.

In other words keep in mind that people might be asking to rewrite this in .net because they believe the application will then magically have increased flexibility, and be able to be changed faster then that of their changing business rules. In fact often the opposite occurs, because access is a very RAD tool. This means that the frontline people can often make modifications due to business rules changing, faster than the IT Dept and their team of developers working away on the next great version of the application. And worse you don't want to saddle that IT Dept and those developers with a poor data model.

I mean, are you to now hire the IT department to build every single spreadsheet and excel for the people because are current business processes are not flexible enough? It would be wonderful if the IT Dept to go around to everybody's desk, hold their hand, and build the excel sheets CORRECTLY for everybody, but it's not practical in the real world. So in addition to taking access away from these people, you might as well take excel away from them also.

I am just pointing out that my spider sense suggests to me that the data models here are going to be a real challenge. Remember, I would always take poor code and great designed data models over the reverse (Great code, but terrible data models). The reason for this is with great data designs, then the code and applications practically write themselves. And with great data models, then the ease of which you can change for the ever changing business rules again favors great data designs over that of great code. You can also RE factor the code overtime WHEN you have good data models. So, with good data models you can move forms and functionality and the UI over into .net, and you can do this seamlessly and easily WHEN the existing data models make sense to keep.

Also it makes no sense to move to these new technologies and less you're going to introduce the possibility of introducing things like self serve web portals for the existing business processes. So, today we can now allow customers to manipulate and use some of that information that is currently locked up in the system. This might be simple as them checking the status of their orders instead of wasting valuable customer phone time. Or it might be something simple like how a major package company in Canada saved an estimated $10,000,000 in the first year of implementing their package tracking system. Or might be something as simple as allowing the customer to look up their account balance.

So right now in the marketplace, these self serve customer web portal systems allow customers to enter and use and get at their information instead of the calling up some employed within the organization who then turns around and launches the application and then manipulates the information for that customer while on the phone. Might just as well let the customer do this work! So from order status, to balances owing, to banking, or what ever it is, the real cherry model ticket today is to allow the customer to use at a cell serve web portal that represents all that valuable information that that internal application is creating .

As mentioned, you have to ask, is where is the Manpower and personnel going to come to build and maintain this application? Obviously the existing system with enormous numbers of forms and tables you are throwing out must somehow been created, and represents some significant investments of time and efforts . The key concept you have to ask, is where were those significant investments and resources coming from to build that existing application? Who is going to maintain the new system then? In other words you need to design the new system to reduce maintenance costs. (new versions of my software can reduce maintenance by as much as 10 or 15 hours per year for customer ).

At the end of the day, good software development and good designs are good designs. Using Access, or VB6, or vb.net don't matter if the system is meeting your business needs now.

I should also point out that the new version of access 2010, can create .web forms. They are XAML (zammel .net forms). I am pointing this out, because changing the front end skin from access to .net yields you VERY little unless the underlying data structures and designs are also modified to take advantages of new possible business processes that can be accomplished with new technologies (such as those cell serve web portals). Simply repaint the font ends with .net forms is really very much amounts to a waste of money in my humble opinion UNLESS other issues are being addressed such as the data model, or some type of web portal that'll improve flexibility here.

You have some great advice here already. Keep in mind this really comes down to what are the goals and reasons for these people desiring this software to be rewritten in .net. Those new goals and desires better not be based on the pretext of simply remaking the forms you have now into .net as that will really accomplish nothing at all, and will not improve their ability to address their changing business needs that the system they are currently using obviously had been doing in the past.

Good luck on this I don't think this is the kind of question that can be answered in a simple forum post, but at least you have lots to chew on here so you can get the ball rolling.

Albert D. Kallal
Agreed that dumping Access is not sufficient reason to rewrite everything. Disagreed with the implication that keeping it is a viable, long-term alternative.
Steven Sudit
Albert didn't say the latter. He said it could be given the right circumstances. If you don't believe it ever is, then you're an anti-Access zealot, and not a pragmatist like Albert and me.
David-W-Fenton
Removing something that allows users to deal with changing business rules only sets things up for failure and does users a great disservice. Next Excel will have to be removed since users flock to that when existing tools are taken away. Access very well may not be appropriate anymore, but then again this might not be an Access issue at all. Do they use Source Code control with access now? How about new web forms ability? Without details we only know that their IT dept allowed the application to grow to an LARGE 650 forms and now they want to take over this application (where were they?).
Albert D. Kallal
Many thanks for the very detailed response, your insight and experience is very helpful. One or two assumptions are not quite correct however, the first is that this application is to be used in-house. It isn't. I've edited my first post to add some more pertinent information.
James Ludlow
You are very welcome. And I not trying to make the case to keep technology x, or technology z, or access. I just wanted to convey that all of this software stuff comes down to working with people and providing them with tools to get their job done. This is your horse track and only you can know what kind of horses you need for your track, not me here in a posting. I much tip my hat to you for being so willing to go out and seek alternate views and suggestions on what is obviously a difficult and large undertaking on your part. There is no magic silver bullet here. Once again, best of luck.
Albert D. Kallal
@David: Actually, I'm a software developer, whereas MS Access is a RAD tool designed primarily to allow non-developers to create something useful to them. The very same things that make it good at that also make it bad at the things I value. MS Access is, for a seasoned developer, *always* the wrong tool. If that makes me a "zealot" in your eyes, so be it. Life is too short to try to please everyone, and honesty is valuable.
Steven Sudit
@Albert: I've seen Excel used as a poor-man's database, too. Doesn't mean we should be poor men.
Steven Sudit
@Steven Sudit: you're basically saying I'm not a developer because I develop in Access. This really is bigotry. While of course Access allows non-developers to accomplish a lot, in the hands of an experienced developer it can do much, much more. If you don't recognize that, it's likely because of ignorance. If it's not, then it's irrational bigotry. Either way, it's not reality-based.
David-W-Fenton
@Steven Sudit: Albert didn't suggest using Excel in place of Access -- he only suggested that if you take Access away from users, they'll fall back to things like Excel. Do you have any level of reading comprehension at all? Or was that just too much for you to absorb in one go?
David-W-Fenton
@David: You're a developer who uses a tool made for non-developers. Draw your own conclusions here. Thanks for the personal attack, but I am neither ignorant nor bigoted. Rather, I've used MS Access, and that is precisely why I know it's a bad tool for actual developers.
Steven Sudit
Access not being a developer tool is just a point of view. If access was not a developer tool then why does Access 2010 have Source code control baked into the product? You think features like VSS source code control support is for non coders and end users? Access is a tool that spans skills from non coders to that of disconnected recordsets and creating of browser neutral web sites on SharePoint, great ribbon development support, and even support for SQL Auzre (cloud sql) is built into the product. Hardly a non developers tool when you talk about web Forms, VSS and even Azure support.
Albert D. Kallal