System.AuthorizedDate が使用されていることは正しいです。
パブリック API を使用して System.AuthorizedDate を変更することはできません。それはあなたをさせません。また、SQL 更新コマンドを使用して System.AuthorizedDate の日付を変更することはできず、サポートされている状態のままです。正式には、Microsoft はこれを許可しておらず、サポート インシデントなどのガイダンスの下で SQL が制定された変更を行わない限り、Microsoft がお客様をサポートする能力を維持しています。
Microsoft へのサポート インシデントが更新クエリを生成するとは思えません。これは欠陥ではなく、後で説明するように、非常に悪い状況に陥る可能性があるためです。System.AuthorizedDate の日付をさかのぼるために、適切なテーブルに一連の更新を作成していただけますか? 間違いなく。うまくいくかもしれませんが、あえてそうしようとしてもうまくいくかどうかはわかりません. その理由は、作業項目が作成時に順番に System.Id 番号を受け取るためです。バージョン管理では、変更セット番号が大きいほど、変更セット番号が小さい場合よりもコミット日が遅くなる(正確なフィールド名を思い出すことができない)というシステムの期待があることを私は知っています。作業項目に対するシステムに同様の期待があったとしても、私は驚かないでしょう。SQL から作業項目のフィールドにそのような変更を加えると、さまざまな場所でエラーや予期しない結果が生じることに気付くかもしれません。将来のアップグレードや更新でさえ、単純に爆撃されて実行できなくなることを想像できます。ただし、環境をサポートされていない状態にしたくない場合を除き、SQL 経由で環境を変更することはないため、これはすべて仮説です。
評価が異なる独自のバーンダウンを作成する以外に、それらの条件下で目的の目標を達成する手段を知りません。