Autoreplicaton on tier-2 and methods to quickly populate tier-2 with tier-1 data

Yes, auto-summary is also applied in the "tier 2" for replicated tags. However, to make it retroactive, you would have to use the backfill utility. 

The general idea in your workflow above is valid, but the order is a little off. It would need to be:

1. Install tier-2 with runtime database and history blocks from tier-1. (TagName = TagA)
2. Shut down tier-2 Historian
3. Tag rename (TagA -> prefix.TagA)
4. Start tier-2 Historian
5. Set up replication from tier-1 to tier-2 (TagName = prefix.TagA)

The reason is that all the historical data is stored based on a TagId. When a source system (in this case, the "tier 1", but can also apply for a AppEngine, SDK app, etc.) first tries to create the destination tag , if it finds a matching (name, type, description, etc.) tag that already exists, it keeps it's existing TagId and uses that rather than creating a new TagId.

One other note: the reason Replication has a "prefix" is to avoid name collisions when consolidating tags from multiple source systems. If the "tier 2" will only have replicated tags from a single source, you don't need to use the prefix and can skip a lot of the steps above.  

Yes, auto-summary is also applied in the "tier 2" for replicated tags. However, to make it retroactive, you would have to use the backfill utility. 

The general idea in your workflow above is valid, but the order is a little off. It would need to be:

1. Install tier-2 with runtime database and history blocks from tier-1. (TagName = TagA)
2. Shut down tier-2 Historian
3. Tag rename (TagA -> prefix.TagA)
4. Start tier-2 Historian
5. Set up replication from tier-1 to tier-2 (TagName = prefix.TagA)

The reason is that all the historical data is stored based on a TagId. When a source system (in this case, the "tier 1", but can also apply for a AppEngine, SDK app, etc.) first tries to create the destination tag , if it finds a matching (name, type, description, etc.) tag that already exists, it keeps it's existing TagId and uses that rather than creating a new TagId.

One other note: the reason Replication has a "prefix" is to avoid name collisions when consolidating tags from multiple source systems. If the "tier 2" will only have replicated tags from a single source, you don't need to use the prefix and can skip a lot of the steps above.  

Thanks for the detailed reply.

The order you described makes a lot of sense, and it is the order that we initially tried to use when renaming tags from System Platform. But some years ago we tried that order and it gave us trouble, so we ended up creating the new tags before renaming and we just stuck with this order because it worked out. I will have to try the new order.

I guess the follow-up regarding the renaming is, if we rename TagA -> prefix.TagA, will this also take care of autoreplicated tags, or would we need to perform additional steps to get this working?

The end result is that we want the same sub-second trend retrival on tier-2 that we already have on tier-1.

Yes, auto-summary "source tags" will be updated as part of the rename.