What is best practice for converting an application designed using CDTs to Records?

Over the pass few years much has changed for data structures within Appian, specifically with record types and custom data types (CDT). There does not seem to be any official documentation on how to convert an application designed using CDTs to one using records. While CDTs have not been entirely fazed out but rather relegated to support with plugins and smart services, it is often more performant and (based on Appian documentation) preferred to build using record types. 

My questions are:

  1. For larger "legacy" systems is there a significant benefit to converting the existing CDTs used in process models, interfaces, rules, etc. to record types?
  2. Is there a fast and efficient way of converting these types from CDT to Record.

  Discussion posts and replies are publicly visible

  • Certified Lead Developer

    1. Yes, but depends on the use case.

    2. No, this is lots of manual labor.

    IMHO there is no urgent need to convert existing apps to records as Appian will support CDTs and datastores for the foreseeable future. When modifying an app, I suggest to refactor existing things towards records when touching them.

  • Certified Senior Developer
    For larger "legacy" systems is there a significant benefit to converting the existing CDTs used in process models, interfaces, rules, etc. to record types?

    Consider converting to Records for speed and easier upkeep, but only if it's causing problems or you're revamping the system anyway.

    Is there a fast and efficient way of converting these types from CDT to Record.

    No, there isn't a fast and automatic way to convert CDTs to Records. Time-consuming but controlled. Recreate record structure, migrate data, update processes/interfaces/rules.

  • Certified Lead Developer

    For #1 - I would say that the main benefit is that Record Types could help you simplify your app so it could help with maintainability in the long term if you often have to make changes to the application. Otherwise, the only benefit could be some performance gains.

    Here is a comprehensive list of all the features enabled by data sync: https://docs.appian.com/suite/help/24.1/records-data-sync.html 

    For #2, as the others have said, I would refactor portions of the app as I touch them.

  • Certified Associate Developer

    Hi Jesse,

    1. If the data volume if very high and the system is legacy, its bit hard to convert into rules using record type, the effort would be very high.

    2. But still you can convert reporting's, and any static data for which the ids are referring in transaction table but the value of that exists in another table. For such things record sync are best. 

    3. I don't think there is a fast and efficient way, its more of rewrite of the rules. But for beginning you can start with #2 which will be more useful.

  • Certified Lead Developer

    CDTs are not being deprecated... And records can be backed by CDTs still, so I guessing you are referring to synced records.

    For existing applications, there is no need to convert - but consider building new when your business case/requirement is to leverage new functionality. It is not technical debt, but instead opportunity to build to enhancements. You can have a CDT backed record and and synced record against the same entity. But do this when you want to take advantage of new features (driven by business needs) to do things like use self-service analytics. 
    If you do have tech debt of a query using a CDT backed record that maybe exceeds the query time limit, maybe then consider switching that to a synced record since that will "fix that tech issue" -- but otherwise, do this based on enhancements requests and needs.