anchor.diff:  for the {transform} checkpoint to complete.
   
   [discrete]
  -[[transform-scheduling-limitations]]
  -== {ctransform-cap} scheduling limitations
  -
  -A {ctransform} periodically checks for changes to source data. The functionality
  -of the scheduler is currently limited to a basic periodic timer which can be 
  -within the `frequency` range from 1s to 1h. The default is 1m. This is designed 
  -to run little and often. When choosing a `frequency` for this timer consider 
  -your ingest rate along with the impact that the {transform} 
  -search/index operations has other users in your cluster. Also note that retries 
  -occur at `frequency` interval.
  -
  -[discrete]
   [[transform-failed-limitations]]
  -== Handling of failed {transforms}
  +=== Handling of failed {transforms}
   
   Failed {transforms} remain as a persistent task and should be handled 
   appropriately, either by deleting it or by resolving the root cause of the 
  
positive.code: 
  [discrete]
  [[transform-consistency-limitations]]
  == {ctransform-cap} consistency does not account for deleted or updated documents
  
  While the process for {transforms} allows the continual recalculation of the 
  {transform} as new data is being ingested, it does also have some limitations.
  
negative.code: ++++
  
  The following limitations and known problems apply to the {version} release of 
  the Elastic {transform} feature. The limitations are grouped into the following 
  categories:
  
  * <<transform-config-limitations>> apply to the configuration process of the 
    {transforms}.
  * <<transform-operational-limitations>> affect the behavior of the {transforms} 
    that are running.
  * <<transform-ui-limitations>> only apply to {transforms} managed via the user 
    interface.
  
  
  [discrete]
  [[transform-config-limitations]]
  == Configuration limitations
  
  [discrete]
  [[transforms-ccs-limitation]]
  === {transforms-cap} support {ccs} if the remote cluster is configured properly
  
  If you use <<modules-cross-cluster-search,{ccs}>>, the remote cluster must 
  support the search and aggregations you use in your {transforms}. 
  {transforms-cap} validate their configuration; if you use {ccs} and the 
  validation fails, make sure that the remote cluster supports the query and 
  aggregations you use.
  
  [discrete]
  [[transform-painless-limitation]]
  === Using scripts in {transforms}
  
  {transforms-cap} support scripting in every case when aggregations support them. 
  However, there are certain factors you might want to consider when using scripts 
  in {transforms}:
  
  * {transforms-cap} cannot deduce index mappings for output fields when the 
    fields are created by a script. In this case, you might want to create the 
    mappings of the destination index yourself prior to creating the transform.
  
  * Scripted fields may increase the runtime of the {transform}.
    
  * {transforms-cap} cannot optimize queries when you use scripts for all the 
    groupings defined in `group_by`, you will receive a warning message when you 
    use scripts this way.
    
  [discrete]
  [[transform-runtime-field-limitation]]
  === {transforms-cap} perform better on indexed fields
  
  {transforms-cap} sort data by a user-defined time field, which is frequently 
  accessed. If the time field is a {ref}/runtime.html[runtime field], the 
  performance impact of calculating field values at query time can significantly 
  slow the {transform}. Use an indexed field as a time field when using 
  {transforms}.
  
  [discrete]
  [[transform-scheduling-limitations]]
  === {ctransform-cap} scheduling limitations
  
  A {ctransform} periodically checks for changes to source data. The functionality
  of the scheduler is currently limited to a basic periodic timer which can be 
  within the `frequency` range from 1s to 1h. The default is 1m. This is designed 
  to run little and often. When choosing a `frequency` for this timer consider 
  your ingest rate along with the impact that the {transform} 
  search/index operations has other users in your cluster. Also note that retries 
  occur at `frequency` interval.
  
  
  [discrete]
  [[transform-operational-limitations]]
  == Operational limitations
  
  [discrete]
  [[transform-rolling-upgrade-limitation]]
  === {transforms-cap} reassignment suspended during a rolling upgrade from 7.2 and 7.3
  
  If your cluster contains mixed version nodes, for example during a rolling
  upgrade from 7.2 or 7.3 to a newer version, {transforms} whose nodes are stopped 
  