You can plan continuity or a transition from MDriven Turnkey by keeping your business model, data requirements, integrations, and operational responsibilities documented throughout the application lifecycle.

What is documented for MDriven Turnkey

MDriven Turnkey is a subscription service for an application site. You can retrieve all of your data at any time and end your subscription. The service states that there is no lock-in and pledges to enable you to keep operations going with MDriven Turnkey.

Your application design is created in MDriven Designer, where you define the information, actions, rules, and views. A ViewModel defines a perspective on information for a specific use case. For example, an order-management application can use one ViewModel for a sales user’s order list and another for an administrator’s operational view.

Plan for transition from the start

Treat transition planning as an application responsibility, not as a task to begin when a subscription ends.

1. Identify the business capabilities that the application supports. For example, list order registration, reservation handling, reporting, and user administration separately.
2. Document the model concepts that implement each capability: classes and relationships, rules expressed in OCL, actions, and ViewModels.
3. Define the data you must be able to retrieve and how you will verify it. For an order-management application, include orders, customers, order lines, statuses, and the relationships between them.
4. Document every external dependency, including integrations, custom front-end components, and custom code. State what each dependency does and who owns it.
5. Keep a current operational runbook. Include the people responsible for the application, access administration, deployment, monitoring, and the steps used to validate a replacement system.
6. Schedule a retrieval and reconciliation exercise while the application is in normal operation. Compare the retrieved data with the records used by the application and record the result.

Preserve the business meaning

The model is where the application’s information, actions, rules, and views are designed. Preserve documentation that explains why each model element exists, not only its name.

For example, a field named Status is not sufficient transition documentation. Record the allowed states, which action changes the state, the rule that controls the change, and which user role can perform it. This gives a successor implementation team the business meaning needed to reproduce the process.

Where access control is important, also document the data slice each ViewModel exposes and the authorization rule behind it. MDriven Turnkey performs ViewModel data reduction on the server. See Information security and AccessGroups, InterestGroups and ViewModel-Enable.

Review transition risks

Risk	What to document	Example
Business rules exist only in the model	Rule purpose, inputs, outputs, and affected data	A reservation rule prevents two users from reserving the same item for the same period.
Data is retrieved without validation	Required entities, relationships, record counts, and reconciliation checks	Confirm that every order line remains connected to its order after retrieval.
Integrations are not understood	Endpoint purpose, data exchanged, authentication responsibility, and failure handling	Record that an accounting integration receives completed orders and how failed deliveries are handled.
Access behavior cannot be reproduced	User roles, ViewModels, and rules controlling persistent-data changes	Record that a sales user can view an order but cannot change a persisted order until the relevant access rule permits it.

See also

• Documentation:MDriven Turnkey Series
• Documentation:How does MDriven work
• Training:Information security
• Documentation:High or low exposure to risk