Obviously a lot of the threads of discussion focus on creating new LLBLGen data access / business logic assemblies from scratch however does anyone have any thoughts on creating an LLBLGen assemby when you already a large existing data access / business logic layer created.

We obviously have quite a bit of business logic in our existing classes and also some workflow e.g. logic called based on a state transition within the object. There is a lot of existing client code using the old framework and want the transition to be as smooth as possible.

Has anyone got ideas on how this can be best managed? I was thinking of keeping most client code the same and having both assemblies i.e. old and new llblgen, used for sometime whilst code is being migrated. New client code can always use the llblgen assembly gradually over time all client code using the old assembly will be removed, removing the need for the old assembly at all.

Thoughts please?

The problem with your approach is that during the transition period when you have both the old and the new LLBLGen assemebly at the same time, you will be facing a maintenance nightmare. If you need to amend or change the business logic you need to do so in two assemblies and using two different programming methodologies. Code maintainability is something that should not be taken lightly in any business applications. I cant claim I have a magic bullet for this scenario. I look at adopting LLBLGen from two perspectives. (1) Use LLBL as a replacement for ADO.NET code. This means I replace all native ADO.NET with LLBLGen adapter code that would use DataTables\DataSets\Parameters to exchange data. (2) Fully adopt LLBL's entities as the main data structures in both the BL and UI tiers. LLBL's entities provide rich data binding support in addition to the obvious benefits of having an OOP interface to the underlaying dataBase.

Depending on how much BL logic lives in your dataAccess layer would dictate how difficult it is to move your dataAccess code to LLBLGen.

The same n-tier best practice of separating BL logic from the UI holds very much true for separating BL logic from that of DAL (Data Access Layer). If your code was architectured into these logical tiers then its just a matter of replacing one DAL with another one that internally uses LLBL (track 1)