Вот такие проектировщики плодят кучу таблиц под одну сущность.
Яркий пример, под каждый год отчетности создают таблицы <название_таблицы>_<год_отчетности>.
Не надо так, пожалуйста.
В вашем случае, ситуация ровно таже самая.
Добавьте в существующий статус задачи еще одно значение - "Архивный", либо создайте отдельный атрибут под этот признак. И, обязательно, проиндексируйте его.
В бизнес-логике очень легко отсеять записи с неподходящим статусом.
Если не хотите, чтобы бизнес-логика видела ненужные записи, делайте для нее свое view.
Есть, конечно, случай, когда таблица становится очень большой, и нужно облегчить накладные расходы по ее хранению, то в этом случае настраивают партиции таблицы. Но это тонкое администрирование.
PS: Если задача требует переноса данных в один присест и это не ошибка проектирования архитектуры, то это выполняется как любое неэлементарное действие с помощью транзакций в процедурном режиме выполнения SQL:
- открываем транзакцию;
- делаем insert с select;
- делаем delete;
- закрываем транзакцию.
Только имейте ввиду, что в транзакции не должны прогонятся длинные выборки ни в insert-е, ни в delete. Это влияет на время блокировки таблиц, и сильно затратно по производительности, так как существенно перестраиваются индексы. Нужно аккуратно использовать такие процедуры (по правилу: "семь раз селекть, один раз делеть"), иначе получите залочивание на длительный период.