You can move an existing legacy ECO application from direct database access or another PersistenceMapper to MDrivenServer while retaining its model and existing database.
ECO (Enterprise Core Objects) is the former name of the technology now delivered as MDriven. This migration puts MDrivenServer between your application and the database. Your client then connects to MDrivenServer rather than directly to SQL Server or another database provider.
What changes in this migration
MDrivenServer receives the model from MDriven Designer and uses that model when it accesses data. It can create or evolve the database used for the model. MDriven Framework applications can use the MDriven Framework PersistenceMapper API to work with the server; the API supports transactions, CRUD operations, optimistic locking, client synchronization, and OCL queries executed as SQL in the database.
| Area | Before migration | After migration |
|---|---|---|
| Client data connection | The WinForms, WPF, or MVC client connects directly to the database, or uses another PersistenceMapper. | The client connects to MDrivenServer using a server account. |
| Database knowledge in the client | The client must know the database connection setup. | The server owns the database connection setup; the client does not need database credentials or database connection configuration. |
| Model deployment | The model is used by the existing application and persistence setup. | MDriven Designer uploads the model to MDrivenServer. |
| Data inspection | You inspect data with database tools or the application. | You can inspect data in the MDrivenServer web interface, including Data in A0. |
Before you start
Make the migration against a copy or controlled environment of the existing database until you have confirmed that the server evolution makes no unintended changes. The important check is that the model uploaded to MDrivenServer matches the mapping already used by the database.
Review the following before changing the client:
- Confirm that you have the MDriven model that represents the existing database.
- Identify the current PersistenceMapper and its mapping settings.
- Identify the database provider and the connection string for the existing database.
- Ensure that you can test the application after changing its connection from the database to MDrivenServer.
- If the database was not originally created from the current model, review DB Reverse before uploading a model that may evolve it.
Migration procedure
1. Install and reach MDrivenServer
Install MDrivenServer on IIS, or use the MDrivenServer core for self-hosting on .NET 5. Confirm that you can reach its web interface before changing your application.
For installation, server configuration, and maintenance guidance, see HowTos:Configure and Maintain MDriven Server.
2. Configure server accounts and registration
Secure the server with accounts before connecting an application.
- Create an account for the application. The client will use this account and its password when it connects to MDrivenServer.
- Create a separate administrator account for your own administration work.
- Create an account named
awhen you plan to use MDriven Turnkey, because Turnkey assumes that account name. - Turn off registration of new accounts after the required accounts exist.
Do not use the administrator account as the application's runtime account. Keeping those accounts separate makes it clear which access is used by the deployed application and which is used for server administration.
3. Upload the model to MDrivenServer
- Open the model in MDriven Designer.
- Use the Designer Cloud Dialog to upload the model to MDrivenServer.
- Confirm that the server has received the intended model before pointing it at the existing database.
MDrivenServer uses model updates received from MDriven Designer as part of its development and deployment loop. The upload is therefore a model deployment step, not a client-connection change.
4. Point MDrivenServer to the existing database
Change the MDrivenServer database preference to the database provider used by the existing database, such as MSSql or MySQL. Enter the connection string for that existing database.
At this point, the database connection belongs on MDrivenServer. Do not distribute that connection string to migrated clients.
5. Verify database evolution before continuing
Upload the model again after configuring the external database. Inspect the resulting evolution and verify that it proposes no changes to the existing database.
For example, if your legacy ECO application already uses tables that match the uploaded model and mapping, the expected result is an evolution with no database changes. If the server proposes table, column, or relationship changes that you do not expect, stop the migration and reconcile the model and mapping before proceeding.
This verification is the key safeguard in the migration: it confirms that MDrivenServer can use the existing database without altering its structure.
6. Inspect existing data through the server
Open the MDrivenServer web interface and use Data in A0 to inspect data through MDrivenServer.
Check data that is representative of your application, such as:
- An object with ordinary attribute values.
- An object with associations to other objects.
- Data used by a key application workflow.
This confirms that the server, model, and database connection operate together before you modify the client.
For an overview of the available server interfaces, see Documentation:MDriven Server User/Web interface. MDrivenServer also provides JSON-based access for applications that are not built with MDriven Framework.
7. Change the client to connect to MDrivenServer
Change each WinForms, WPF, or MVC client from its direct-SQL configuration, or from its previous PersistenceMapper, to the MDrivenServer connection supported by your application. Configure it with the MDrivenServer address and the application account created earlier.
A migrated client should authenticate to MDrivenServer with its server account and password. It should no longer require direct database connectivity for its normal data operations.
The exact client-side connection type depends on the PersistenceMapper configuration used by the legacy application. In particular, MSSqlServerLegacyECOMapping is the old ECO3 mapping. Preserve the mapping that matches the existing database; changing the mapping during this migration can cause the model-to-database comparison to propose unwanted evolution changes.
If your existing application uses the ECO WCF client/server bridge, review Documentation:Using different WCF Bindings with Enterprise Core Objects â ECO â MDriven framework for the client endpoint and server binding configuration. That bridge handles queries, fetches, lazy loading, updates, and refreshes between an ECO client and server.
8. Test the application behavior
Run the application through the same workflows you used before the migration. Verify at minimum that it can:
- Authenticate to MDrivenServer.
- Load the data required by its main screens.
- Create, update, and delete data where those operations are part of the application.
- Save changes in transactions.
- Read associated data and any data that is loaded on demand.
For example, if a WPF client previously loaded a customer, changed an address, and saved the change directly to SQL Server, perform that same workflow after the client is connected to MDrivenServer. Confirm that the updated value is visible in both the application and Data in A0.
Do not proceed to a Turnkey evaluation until the migrated application behaves as it did before the connection change.
Next step: evaluate Turnkey
After the legacy application works through MDrivenServer, you are prepared to evaluate it in MDriven Turnkey for a web experience with streaming data and live updates. The required a account should already exist if you followed the account setup in this guide.
Migration checklist
- MDrivenServer is installed and its web interface is reachable.
- Application, administrator, and (when needed)
aaccounts exist. - New-account registration is turned off.
- The intended model has been uploaded from MDriven Designer.
- MDrivenServer is configured with the existing database provider and connection string.
- A second model upload shows no unexpected database evolution.
- Existing data is visible through Data in A0.
- The client connects to MDrivenServer using the application account.
- Core application workflows work as they did before the migration.