Have you reached a point in your application where you want to rewrite some portion of the code, change a public API or even switch to one of the third party components that are widely used today? It's very likely that you've bumped into this wall like most of the developers out there and you know that usually a comprehensive evaluation of the pros and cons of the switch is required to ensure the same improvement can't be achieved with some small tweaks in the existing solution. Either way, you might end up fighting with strange issues and spending
tons of time that might have been instead invested in new features development.
That being said, the OpenAccess ORM team knows that while it is easier to start your project with our ORM solution from the very start, this is not always the case for many of our users and you probably have legacy projects as well - usually based on Entity Framework or LINQ to SQL. Should you consider a migration from any of these two ORM frameworks to OpenAccess, there are two ways for us to assist you:
If you want to create an OpenAccess model and you already have a database, the best way to go is to generate the model automatically using the Database First approach. However, if you have customizations on your old model, you would have to redo them in the OpenAccess Visual Designer. In order for us to take over this mundane task, we are also offering convertion wizards that will do that for you in minutes. Take a look at the new tutorials we have prepared, showcasing how quickly you can convert your database applications started in Entity Framework or in LINQ to SQL.
Once your model is converted automatically, the next steps are covering the differences in:
Those migration actions might not be straight forward and require manual efforts and attention. In order to help you out there we are proud to present a bunch of new resources that are now readily available - our Entity Framework and LINQ to SQL migration guides, covering the major differences and the most common issues. Do not hesitate to give your feedback, as it will immediately be added to those repositories of migration knowledge and might help many developers with a similar scenario.
As you can see, you don't have to keep your legacy applications using different ORM solutions. Stay tuned as the next migration guide we are going to offer will help you replace an ADO.NET custom data layer with Telerik OpenAccess ORM!
Ivailo Ivanov is Team Lead in Telerik Data Access