In T882#14939, @Qgil wrote:

Should we settle on old-bugzilla.wikimedia.org

This is decided: T366

and point the links there?

Still to be decided.

This task is not essential, it has a risk of overcomplicating the migration process, and it can be done afterward either with direct changes to the database or a bot.

Of course since bugzilla.wikimedia.org URLs will redirect (T40), a bz65088 link would have to be to the read-only frozen https://old-bugzilla.wikimedia.org/show_bug.cgi?id=65088

I confusedly suggested an alternative

or it could represent as "bug 65088" and let T687 make it a link.

That probably wouldn't work, since clicking it would just end up at the Phabricator task report you're looking at.

I agree this isn't essential, the migration will be perfect :)

Links should go to https://static-bugzilla.wikimedia.org/ and not https://old-bugzilla.wikimedia.org/ as the former will be permanent while the latter is only temporary.

In T882#1274523, @JohnLewis wrote:

Links should go to https://static-bugzilla.wikimedia.org/ and not https://old-bugzilla.wikimedia.org/ as the former will be permanent while the latter is only temporary.

Links should go where the information is.

In T882#1274614, @Nemo_bis wrote:

In T882#1274523, @JohnLewis wrote:

Links should go to https://static-bugzilla.wikimedia.org/ and not https://old-bugzilla.wikimedia.org/ as the former will be permanent while the latter is only temporary.

Links should go where the information is.

Yes, static-bugzilla has the same information with the added benefit of being permanent.

The new URL for the site with complete (bug) information and searchability is http://bugs.wmflabs.org/

I expect most average users to not care about data not migrated from Bugzilla as it requires knowing about that and realizing the lack of some info.

Power users who do remember what Bugzilla was/is and need to access such non-migrated data more often could e.g. run a Greasemonkey script in their browser:

// ==UserScript==
// @name		Wikimedia Phabricator Maniphest script
// @description		Link a Phabricator task to its old Bugzilla counterpart
// @include		https://phabricator.wikimedia.org/T*
// @grant		none
// @license		The contents of this file are dual-licensed under the Mozilla Public License 2.0
//                      (MPL-2.0) and the GNU General Public License (GPL-2.0) Version 2 or later.
// ==/UserScript==

// var url = "https://static-bugzilla.wikimedia.org/show_bug.cgi?id=";
var url = "http://bugs.wmflabs.org/show_bug.cgi?id=";

if (document.getElementsByClassName('phui-crumb-name').length > 1) {
  var taskId = document.getElementsByClassName('phui-crumb-name')[1].innerHTML;
}

if (taskId &&
    (taskId.substring(1) < 75682) &&
    (taskId.substring(1) > 1999) &&
    (document.getElementsByClassName('phui-header-subheader').length > 0) &&
    (document.getElementsByClassName('phui-crumb-name').length > 0)
   ) {
  var linkOldBz = document.createElement("a");
  var bzID = taskId.substring(1) - 2000;
  linkOldBz.setAttribute('href', url + bzID);
  linkOldBz.setAttribute('id', "bz_link");
  linkOldBz.appendChild(document.createTextNode("(bz" + bzID + ")"));
  linkOldBz.setAttribute('style', "margin: 0px 0px 0px 10px; text-align: left; font-style: italic;");
  var place = document.getElementsByClassName('phui-header-subheader')[0];
  place.parentNode.insertBefore(linkOldBz, place);
}

(Regarding that shabby JS code above: Instead of adding a link to the task summary, linking the existing "Reference" value would be the obvious way but there is no unique ID to get that DOM element and the number of elements is not stable either.)

I could make a custom field in phabricator to link it but I don't know how to hook that up to the existing reference field because we didn't use php-backed custom field for reference

I don't think many folks still look up stuff on https://static-bugzilla.wikimedia.org/ nowadays. Proposing to decline.