Migrating Existing non-SF applications to SF?


Author
Message
Alex Luyando
Alex Luyando
StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)
Group: StrataFrame Users
Posts: 112, Visits: 1.2K
Hi all -

I am not seeing any posts or information in the SF documentation that discusses what options--if any--exist for facilitating the migration of a non-SF C# application to SF. I guess a different way to ask the same question would be: How does one go about introducing the SF framework into an existing C# project?

Any suggestions are appreciated.

Regards, al     

________________
_____/ Regards,
____/ al

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
Well, this is the first time anybody has ever even mentioned this...that would be a good reason there is no documentation explaining this...and there is not really a whole lot to say on this topic.

The primary reason that you do not want to take your existing projects and try and implement the SF core logic is because SF changes the core of how a standard .NET app communicates with the data/application logic/etc., so there are some foundational components that would be really difficult to just "slap" in there.

Your best approach is to go the other way.  Create a SF application from scratch, that is clean, then add your existing program logic into the new SF project a piece at a time.  If you try and go the other way you will never totally work through all of the issues. 

This is the approach that even I would take if I were in the same circumstances.  I am sure that all of this will make more sense after training, but you will be far better off and happier in the long run to create a new project and then start bringing over existing programs and dialogs one by one.  There is no "quick and dirty" way to do this.

Aaron Young
Aaron Young
StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)StrataFrame User (437 reputation)
Group: StrataFrame Users
Posts: 277, Visits: 1.1K
Hi Alex,

I agree with Trent that you are best starting with a new SF application and incorporating your existing code in the new application. I am new to SF and have done just that.

We had a several hundred table application that was years in the development with a rival framework and it wasn't going anywhere fast with a dedicated inhouse programming team and numerous contractors. I bought SF within the last two months and incorporated our code from the old project (dumping the previous frameworks code) and the application is now much better and far more advanced than it ever was with the previous framework. The old project is now sitting idle in Team Foundation Server.

SF has a richness across all levels from the business object level, database deployment, user interface, etc. You will have little or no problems in incorporating your existing code in a clean SF project.

Aaron

Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
SF has a richness across all levels from the business object level, database deployment, user interface, etc. You will have little or no problems in incorporating your existing code in a clean SF project.

I totally agree!  I also took an old project and did the same thing that Aaron did.  Total time from start to finish...about 5 months (includes the not-so-steep learning curve)...AND, I have a ton more functionality to offer the users.  It is an excellent framework and you will not regret following the approach Trent and Aaron laid out for you.

Regards,
Bill

Alex Luyando
Alex Luyando
StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)
Group: StrataFrame Users
Posts: 112, Visits: 1.2K
Thanks all! From my past journeys down similar roads with other technologies (most recently Visual FoxPro and some third-party frameworks) the replies are pretty much what I expected, and clearly doing as you all suggest will add benefits and functionality to the existing applications once moved over.



I think it would be great to be able to just "back fill" a framework into an existing application (especially very large, complex ones) and be able to leverage at least some of the framework's infrastructure and features for at least new components or modifications, but I can see how that can be a complex bridge to cross and most likely not significantly revenue-producing for the framework developer (and I mean that in the nicest way!).



Have a great 4th!

________________
_____/ Regards,
____/ al
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search